[Trad] [svn:pgfr] r1367 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Mar 28 Juil 21:33:13 CEST 2009
Author: daamien
Date: 2009-07-28 21:33:13 +0200 (Tue, 28 Jul 2009)
New Revision: 1367
Modified:
traduc/trunk/slony/faq.xml
Log:
relecture faq 99.99%
Modified: traduc/trunk/slony/faq.xml
===================================================================
--- traduc/trunk/slony/faq.xml 2009-07-25 15:11:31 UTC (rev 1366)
+++ traduc/trunk/slony/faq.xml 2009-07-28 19:33:13 UTC (rev 1367)
@@ -1333,17 +1333,14 @@
</answer>
-<!-- todo -->
<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
-linkend="table.sl-log-1"/> n'aura plus de tables à trouver et par conséquence la requête tombera en erreur. S'un jeu de réplication de nouveau <emphasis>avec</emphasis>
-des tables reapparît, tout va fonctionner correctement; il
- <emphasis>paraîtra</emphasis> tout simplement effrayant.
+<para> Le problème avec un ensemble de réplication contenant uniquement des séquences, ce sont les cas ou les seuls abonnements actifs sont composés uniquement de séquences. Si un noeud entre dans cet état,
+la réplication échouera, puisque la requête qui collecte les données dans <xref
+linkend="table.sl-log-1"/> ne trouvera aucune table et par conséquent la requête sera malformée et échouera. Si un ensemble de réplication <emphasis>contenant</emphasis> des tables reapparaît, tout va fonctionner correctement; cela <emphasis>parait</emphasis> effrayant.
</para>
-<para> Ce problème devrait être résolu un certaine temps après &slony1;
+<para> Ce problème devrait être résolu après &slony1;
1.1.0.</para>
</answer>
</qandaentry>
@@ -1351,19 +1348,18 @@
<qandaentry>
<question><para>Je dois supprimer une table d'un ensemble de réplication</para></question>
<answer><para>
-Ceci peut être accompli de plusieurs manières, pas toutes également souhaitables;-).
+Ceci peut être accompli de plusieurs manières, pas toutes également souhaitables ;-).
<itemizedlist>
-<listitem><para> Vous pourriez supprimer tout le jeu de réplication, et les recréer avec juste les tables dont vous avez besoin. Hélas, ce signifie reproduire un tas de données, et tue l'intérêt du cluster sur lequel cela se produit.</para></listitem>
+<listitem><para> Vous pourriez supprimer tout le jeu de réplication, et les recréer avec juste les tables dont vous avez besoin. Hélas, ce signifie reproduire un tas de données, et interromp la réplicationdes autres éléments de l'ensemble pendant toute la duréel'opération</para></listitem>
-<listitem><para> Si vous êtes en version 1.0.5 ou supérieur, il y a une commande SET DROP TABLE, qui fera "l'affaire."</para></listitem>
+<listitem><para> Si vous êtes en version 1.0.5 ou supérieur, il y a une commande SET DROP TABLE, qui "fera l'affaire."</para></listitem>
-<listitem><para> Si vous employez toujours 1.0.1 ou 1.0.2, l'
-<emphasis>essentiel de la fonctionnalité de <xref linkend="stmtsetdroptable"/>
-impliquant <function>droptable_int()</function> est présent.
-Vous pouvez feuilleter cela à la main en trouvant l'identification de la table à supprimer, et que vous pouvez trouver dedans<xref
-linkend="table.sl-table"/>, et après lancer les trois requêtes suivantes sur chaque noeud :</emphasis>
+<listitem><para> Si vous utilisez toujours une version 1.0.1 ou 1.0.2,
+<emphasis>la fonctionnalité essentielle de <xref linkend="stmtsetdroptable"/> se trouve dans la fonction <function>droptable_int()</function> .
+Vous pouvez l'utilisez à la main en trouvant l'identifiant de la table à supprimer, qui se trouve dans la table <xref
+linkend="table.sl-table"/>, puis lancer les trois requêtes suivantes sur chaque noeud :</emphasis>
<programlisting>
select _slonyschema.alterTableRestore(40);
@@ -1371,25 +1367,24 @@
delete from _slonyschema.sl_table where tab_id = 40;
</programlisting></para>
-<para>Le schéma dépendra évidemment de la façon dont vous avez défini le cluster &slony1;. L'identifiant de la table, dans cet exemple, 40, sera à vous de remplacer par celui que vous voulez vous en débarrasser.</para>
+<para>Évidement le nom du schéma dépend de la façon dont vous avez défini le cluster &slony1;. L'identifiant de la table, dans cet exemple: 40, doit être remplacé par celui de la table dont voulez vous débarrasser.</para>
-<para> Vous devrez lancer ces trois interrogations sur tous les noeuds, de préférence premièrement sur le noeud d'origine, de sorte que la réplique de ses propagations soit correcte.
-Implémenter ceci à travers un ordre de <xref linkend="slonik"/>
-avec un nouveau &slony1; pourra se faire. La soumission des trois requêtes utilisant <xref linkend="stmtddlscript"/> peut le faire aussi.
-Également il sera possible de se connecter à chaque base de données et de lancer les requêtes à la main.</para></listitem> </itemizedlist></para>
+<para> Vous devrez lancer ces trois interrogations sur tous les noeuds, de préférence premièrement sur le noeud d'origine, de sorte que la suppressions se propage correctement.
+On peut également Implémenter ceci à travers un commande <xref linkend="slonik"/> et
+un nouvel évenement &slony1;. Soumettre les trois requêtes en utilisant <xref linkend="stmtddlscript"/> permet de le faire.
+Il est égalementt possible de se connecter à chaque base de données et de lancer les requêtes à la main.</para></listitem> </itemizedlist></para>
</answer>
</qandaentry>
<qandaentry>
-<question><para>Je dois supprimer un ordre dans une séquence pour un ensemble de réplication</para></question>
+<question><para>Je dois supprimer une séquence dans une séquence pour un ensemble de réplication</para></question>
-<answer><para></para><para>Si vous êtes en version 1.0.5 ou supérieur, il y a une commande <xref linkend="stmtsetdropsequence"/> dans Slonik vous permettant de le faire en paralelle <xref linkend="stmtsetdroptable"/>.</para>
+<answer><para></para><para>Si vous êtes en version 1.0.5 ou supérieure, il existe une commande <xref linkend="stmtsetdropsequence"/> dans Slonik vous permettant de le faire en paralelle <xref linkend="stmtsetdroptable"/>.</para>
-<para>Si vous êtes en version 1.0.2 ou antérieur, l'opération sera un peu plus manuel.</para>
+<para>Si vous êtes en version 1.0.2 ou antérieure, l'opération sera un peu plus manuelle.</para>
-<para>À supposer que je veux me débarrasser des deux ordres énumérés ci-dessous,<envar>whois_cachemgmt_seq</envar> and
-<envar>epp_whoi_cach_seq_</envar>, we start by needing the
-<envar>seq_id</envar> values.
+<para>À supposer que je veux me débarrasser des deux séquences suivante : ,<envar>whois_cachemgmt_seq</envar> et
+<envar>epp_whoi_cach_seq_</envar>, tout d'abord il nous faut les valeurs de <envar>seq_id</envar>.
<screen>
oxrsorg=# select * from _oxrsorg.sl_sequence where seq_id in (93,59);
@@ -1400,7 +1395,7 @@
(2 rows)
</screen></para>
-<para>Les données à supprimer, afin d'éviter que soit propager, nécessite l'arrêt de Slony :
+<para>Les données à supprimer pour empêcher Slony de continuer la réplication sont :
<programlisting>
delete from _oxrsorg.sl_seqlog where seql_seqid in (93, 59);
@@ -1408,39 +1403,39 @@
</programlisting></para>
<para>Ces deux interrogations peuvent être soumises à l'ensemble des noeud via la fonction &funddlscript; / <xref
-linkend="stmtddlscript"/>, éliminant l'ordre partout en
-<quote>même temps.</quote> Ou bien appliquer à la main à chacun des noeuds.</para>
+linkend="stmtddlscript"/>, éliminant la séquence partout
+<quote>en même temps.</quote> Ou bien on peut les appliquer à la main à chacun des noeuds.</para>
-<para>Similarly to <xref linkend="stmtsetdroptable"/>, this is
-implemented &slony1; version 1.0.5 as <xref
+<para>De la même manière que <xref linkend="stmtsetdroptable"/>,
+cette fonction est implementée dans &slony1; version 1.0.5 sous
+le nom <xref
linkend="stmtsetdropsequence"/>.</para></answer></qandaentry>
</qandadiv>
-<qandadiv id="faqobsolete"> <title> &slony1; FAQ: Hopefully Obsolete Issues </title>
+<qandadiv id="faqobsolete"> <title> &slony1; FAQ: Problèmes devenus obsolètes</title>
<qandaentry>
<question><para> &lslon; ne se remet pas en marche après un incident</para>
-<para> Après un après brutal de &postgres; (en simulant une panne système)
-dans &pglistener; un tuplets existe avec <command>
+<para> Après un arrêt immédiat de &postgres; (équivalent à un crash du système),
+dans la table &pglistener; on trouve un tuple contenant <command>
relname='_${cluster_name}_Restart'</command>. slon ne démarre pas car
-il considère qu’une autre processe sert le cluster sur ce noeud. Que puis-je faire?
-Le tuplet ne peut pas être supprimé dans la relation.</para>
+il considère qu'un autre processus gère le cluster sur ce noeud. Que puis-je faire?
+Le tuple ne peuventt pas être supprimés dans cette relation.</para>
-<para> Le journal prétend que <blockquote><para>un autre slon en tâche de fond
-sert ce noeud déjà</para></blockquote></para></question>
+<para> Les journaux de traces indique qu' <blockquote><para>un autre slon en tâche de fond gère déjà ce noeud.</para></blockquote></para></question>
<answer><para> Le problème est que la table système &pglistener;, utilisée par
-&postgres; à gérer l'évènement de notification, contiens quelques entrées pointant vers le central,
-n'existent plus. La nouvelle instance de <xref
-linkend="slon"/> se connecte à la base, et elle est convaincue, par la
+&postgres; pour gérer les notification d'évènements, contient quelques entrées pointant vers des processus qui n'existent plus.
+La nouvelle instance de <xref
+linkend="slon"/> se connecte à la base, et elle est convaincue, à cause de la
présence de ces entrées qu'un ancien
<application>slon</application> est toujours en activité pour s'occuper de ce noeud de &slony1;.</para>
-<para> Le <quote>détritus</quote> dans cette table doit être nettoyer.</para>
+<para> Les <quote>détritus</quote> dans cette table doivent être nettoyés.</para>
-<para>Il sera utile de maintenir un script manuel pour ce genre de situation:
+<para>Il est utile de maintenir un script manuel pour ce genre de situation:
<programlisting>
twcsds004[/opt/twcsds004/OXRS/slony-scripts]$ cat restart_org.slonik
@@ -1456,16 +1451,16 @@
</programlisting></para>
<para> <xref linkend="stmtrestartnode"/> nettoie les notifications mortes
-pour en suite redémarrer le noeud.</para>
+pour qu'on puisse ensuite redémarrer le noeud.</para>
-<para>Comme en version 1.0.5, au démarrage de slon, les processes cherche ce genre de données obsolètes et les nettoient
+<para>A partir de la version 1.0.5, le processus de démarrage de sloncherche ce genre de données obsolètes et les nettoient
le cas échéant.</para>
-<para> Comme en version 8.1 de &postgres;, la fonction manipulant
-&pglistener; ne supporte pas cet usage, alors pour la version de &slony1; après
-1.1.2 (<emphasis>e.g. - </emphasis> 1.1.5), ce
-<quote>couplage</quote> est manipulé par l'intermédiaire d'une autre table, et l'issu de la situation est
-rendu un peu plus transparent. <quote>.</quote> </para>
+<para> A partir de la version 8.1 de &postgres;, la fonction manipulant
+&pglistener; ne supporte pas cet usage, alors pour les versions de &slony1; postérieurs à la
+1.1.2 (<emphasis>e.g. - </emphasis> 1.1.5), ce risque d'
+<quote>inter-blocage</quote> est géré vias une nouvelle table,
+et le problème disparait de manière transparente. <quote>.</quote> </para>
</answer></qandaentry>
@@ -1479,8 +1474,7 @@
ERROR: could not find hash function for hash operator 716373
</programlisting>
-<para> Il semble que &slony1; <function>xxid</function> les fonctions vont être
-dôtées de brouillage(hashing), qu'elles n'ont pas actuellement.</para>
+<para> Il semble que les fonctions <function>xxid</function> de &slony1; prétendent pouvoir faire du hashing, mais qu'elles n'y arrivent pas.</para>
<para> Que se passe-t-il ? </para>
@@ -1488,29 +1482,29 @@
</question>
<answer><para> &slony1; a défini un nouveau type de données et d'opérateurs XXID
-ce type afin de permettre la manipulation des IDs de transaction qui sont employés
-pour grouper ensemble, les mises à jour qui sont associées à la même transaction.
+afin de permettre la manipulation des IDs de transaction qui sont employés
+pour grouper ensemble, les mises à jour qui sont associées dans une même transaction.
</para>
-<para> Opérateurs qui n'étaient pas disponible pour &postgres; version
-7.3 et inférieur; afin de le rendre opérationnelle en 7.3, les fonctions spécifiques
+<para> Ces opérateurs n'étaient pas disponible pour &postgres; version
+7.3 et inférieur; afin de rendre &slony1; opérationnel avec la version 7.3, des fonctions spécifiques
doivent être ajoutées. L'opérateur <function>=</function>
-a été marqué comme soutenant
-le hachage, mais pour que celui-ci travaille correctement, l'opérateur de jointure doit
-apparaître dans une classe d'opérateur d'index haché. Cela n'a pas été défini,
+a été marqué comme supportant
+le hachage, mais pour que cela fonctionne, l'opérateur de jointure doit
+apparaître dans une classe d'opérateur d'index haché. Cela n'a pas été défini ainsi,
et en conséquence, les requêtes (comme celle ci-dessus) qui décident d'employer
-le hash-joins échoueront. </para> </answer>
+des hash-joins échoueront. </para> </answer>
<answer> <para> Ceci <emphasis> n'a pas </emphasis>
-été considéré comme bug <quote>release-critical</quote>, comme &slony1;
-ne produit probablement pas des intérrogations intérnes employant des hash-join. Ce problème ne devrait
-pas entacher &slony1; devant la capacité qu'il a de gérer la réplication. </para> </answer>
+été considéré comme bug <quote>critiques</quote>, car &slony1;
+ne produit pas de requêtes employant des hash-join. Ce problème ne devrait
+pas perturber la réplication. </para> </answer>
-<answer> <para> La nouvelle version de &slony1; (<emphasis>e.g.</emphasis>
-1.0.6, 1.1) omettra l'indicateur <command>HASHES</command>, donc ceci
+<answer> <para> Les versions suivantes de &slony1; (<emphasis>par exemple :</emphasis>
+1.0.6, 1.1) omettent l'indicateur <command>HASHES</command>
</para> </answer>
-<answer> <para> Supposons que vous souhaitez réparer une instance existante, et vous constatez
+<answer> <para> Supposons que vous souhaitiez réparer une instance existante, et vous constatez
que vos propres scripts ne fonctionneront pas bien, vous pouvez suivre la démarche suivante : </para>
<programlisting>
@@ -1545,25 +1539,30 @@
</qandaentry>
<qandaentry> <question><para> Je peux faire un <command>pg_dump</command>
-et chargez les données en les sauvegardant, beaucoup plus rapidement que si <command>SUBSCRIBE
-SET</command> les exécutait lui-même. Pourquoi c'est ainsi? </para></question>
+et rechargez les données beaucoup plus rapidement qu'avec <command>SUBSCRIBE
+SET</command>. Comment est-ce possible ? </para></question>
-<answer><para> &slony1; dépend des index, supposons qu'il soit sur un clef primaire, dont les feuilles se trouvant isolées (sans branches), en utilisant la commande
- &postgres; <command>COPY</command> les données sont lues rapidement.
-Alors que il peut y avoir une dégradation de performance, provoquée par l'évènement <command>COPY SET</command> (un
-évènement généré par le souscripteur) dans la mesure où l'opération dans ce cas démarre par d'abord une suppression des contenus des tables, et rien que cela laisse des tuplets morts.</para>
+<answer><para> &slony1; dépend de l'existance d'un index sur la clef primaire
+et ne touche pas aux autres index pendant l'opération &postgres; <command>COPY</command> qui charge les données.
+Par ailleur il peut y avoir une dégradation de performance, provoquée par l'évènement <command>COPY SET</command> (un
+évènement généré lors d'un abonnement) dans la mesure où l'opération commence par une suppression des contenus des tables, ce qui laisse la tables remplie de tuples morts.</para>
-<para> Lorsque vous utilisez <command>pg_dump</command> pour exporter le contenus de la base, et que vous les re-importez après, les indexes ne sont crées qu'à la fin. Ceci est <emphasis>beaucoup</emphasis> plus performant des reconstruire les indexes sur une table entièrement re-importée, plutôt que de refaire les indexes à la volet lorsque les enregistrement sont rajoutés un à un à la table.</para></answer>
+<para> Lorsque vous utilisez <command>pg_dump</command> pour exporter le contenus de la base, et que vous les re-importez après, les indexes ne sont crées qu'à la fin.
+Il est <emphasis>beaucoup</emphasis> plus performant de reconstruire les indexes sur une table entièrement re-importée, plutôt que de refaire les indexes à la volée lorsque les enregistrements sont rajoutés un à un à la table.</para></answer>
-<answer><para> Si d'emblée, vous pouvez supprimer des indexes inutiles, lorsque <command>COPY</command> se met en marche, les performances sont sensiblement améliorée. Encore mieux, si vous pouvez<command>TRUNCATER</command> les tables dont le contenu devra disparaître, les performance vont augmenter d'<emphasis>avantage.</emphasis> </para></answer>
+<answer><para> Si vous pouvez supprimer des indexes inutiles, lorsque <command>COPY</command> se met en marche, les performances sont sensiblement améliorée.
+Encore mieux, si vous pouvez faire un <command>TRUNCATE</command> sur les tables dont le contenu devra disparaître, les performances vont augmenter <emphasis>énormément</emphasis>. </para></answer>
-<answer><para> &slony1; en version 1.1.5 et supérieur, fait cela automatiquement; il <quote>cogne</quote> sur les indexes dans le catalogue de &postgres; afin de les inhiber, de plus, de la même façon il désactive les déclencheurs, tout en les <quote>réactivant</quote> à la fin sans oublier de reconstruire les indexes des tables en question. </para> </answer>
+<answer><para> &slony1; en version 1.1.5 et supérieures, fait cela automatiquement;
+il <quote>dégage</quote> sur les indexes dans le catalogue de &postgres; afin de les cacher, de la même façon qu'il cache les triggers,
+puis il <quote>répare</quote> les pointeurs d'index et effectue une
+reindexationd de la table. </para> </answer>
</qandaentry>
<qandaentry id="dupkey">
-<question><para>La réplication échoue - Violation des Constraintes unique</para>
+<question><para>La réplication échoue - Violation de Constrainte Unique</para>
-<para>Alors que la Réplication se déroule correctement, depuis un bout de temps, lorsque le noeud rencontre <quote>intempestivement,</quote> des erreurs suivant envoyées dans le journal:
+<para>Alors que la Réplication se déroule correctement depuis un bout de temps, lorsque que tout a coup 'un noeud rencontre un <quote>soucis</quote> et les erreurs suivantes envoyées dans le journal:
<screen>
DEBUG2 remoteWorkerThread_1: syncing set 2 with 5 table(s) from provider 1
@@ -1588,34 +1587,39 @@
</screen></para>
<para>La transaction s'annule, et &slony1; essaie à nouveau sans cesse.
-Le problème est dû à une des <emphasis>dernière</emphasis> requête SQL
-précisant <command>log_cmdtype = 'I'</command>. Ce n'est pat tout à fait évident; ce qui se passe est que &slony1; regroupe 10 opérations de mise à jour, ensemble, afin de diminuer les aller-retour réseau.</para></question>
+Le problème est dû à une des <emphasis>dernières</emphasis> requêtes SQL, celle qui contenait <command>log_cmdtype = 'I'</command>.
+Ce n'est pas évident du tout;e &slony1; regroupe 10 opérations de mise à jour ensemble, afin de diminuer les allers-retours réseau.</para></question>
-<answer><para> Une origine <emphasis>certaine</emphasis> pour ceci est difficile à déterminer.</para>
+<answer><para> Il est difficile de déterminer avec <emphasis>exactitude</emphasis> l'origine de tout ceci.</para>
-<para>En même temps, nous notons qu'il y a un problème de transactions manquées concernant les suppressions qui sont déjà nettoyées dans <xref
-linkend="table.sl-log-1"/>, et on constate qu'un recouvrement est impossible. A ce stade, ce qui semble nécessaire, est de supprimer le jeu de réplication (ou même carrément le noeud), est de redémarrer la réplication de début pour le noeud.</para>
+<para>En même temps, nous notons qu'il y a un problème : les transactions annulées ont été supprimées dans <xref
+linkend="table.sl-log-1"/>,
+et on constate qu'il est impossible de les récupérer.
+A ce stade, il parait nécessaire de supprimer l'ensemble de réplication (ou même le noeud), et de redémarrer la réplication à partir de zéro pour ce noeud.</para>
<para>Dans &slony1; 1.0.5, l'opération de purge de <xref
linkend="table.sl-log-1"/> devient plus prudente, en refusant
-de purger des entrées qui n'ont pas encore été synchronisées. pour au moins 10 minutes sur l'ensemble des noeuds. Il n'est pas certain que ceci empêche que
-<quote>le problème</quote> ait lieu, mais il paraît plausible que cela laisse assez de volume dans <xref linkend="table.sl-log-1"/> permettant un recouvrement ou bien de permettre d'au moins de diagnostiquer plus exactement la situation. Et peut-être que le problème venait du fait que <xref linkend="table.sl-log-1"/> a été brutalement purgée, donc cette solution permet de résoudre complètement ce genre d'incident.</para>
+de purger des entrées qui n'ont pas encore été synchronisées, pendanttr au moins 10 minutes sur l'ensemble des noeuds. Il n'est pas certain que ceci empêche que
+<quote>le problème</quote> ait lieu, mais il paraît plausible que cela laisse assez de données dans <xref linkend="table.sl-log-1"/> permettant un recouvrement ou bien de permettre d'au moins de diagnostiquer plus exactement la situation.
+Et peut-être que le problème venait du fait que <xref linkend="table.sl-log-1"/> était brutalement purgée, donc cette solution permet de résoudre complètement ce genre d'incident.</para>
-<para> C'est une honte de reconstruire un réplication volumineuse sur un noeud,
-si vous découvrez que le problème pérciste. La bonne idée serai de diviser la réplication
-en plusieurs morceaux afin de dimin<envar>tgrelid</envar> en les pointant sur l'identifiant OID of the <quote>primary
-key</quote> index on the table rather than to the table
-uer la charge de travail lors de redémarrage de réplication.
-Si un seul jeu est cassé, vous n'auriez qu'à désabonner et supprimer celui-ci.
+<para> C'est une honte de devoir reconstruire une réplication volumineuse sur un noeud à cause de cela.
+Si vous découvrez que le problème persiste,
+La bonne idée serait de diviser la réplication
+en plusieurs ensemble de réplication afin de dimininuer
+la charge de travail lors de la reconstruction de la réplication.
+Si un seul ensemble est cassé, vous n'auriez qu'à désabonner et supprimer celui-ci.
</para>
-<para> Dans un cas, nous avons trouvé deux lignes dans le journal d'erreur des requêtes sql
-qui sont <emphasis> identique </emphasis> concernant l'insertion dans
- <xref linkend="table.sl-log-1"/>. Ceci <emphasis> doit
+<para> Dans un cas, nous avons trouvé dans le journal de trace deux lignes <emphasis> identiques </emphasis> concernant l'insertion dans
+ <xref linkend="table.sl-log-1"/>.
+Ceci <emphasis> devrait
</emphasis> être impossible d'autant plus qu'il s'agit d'une clef primaire sur <xref
-linkend="table.sl-log-1"/>. La dernière théorie, moins forte, laisserait à penser que cette situation
-viendrait que <emphasis>cette</emphasis> clé serait peut-être corrompue (présence d'un bug de &postgres;), et afin de soulever ce doute,
-on peut exécuter l'ordre suivant:</para>
+linkend="table.sl-log-1"/>. La dernière théorie sur le sujet laisserait à penser que cette situation
+viendrait du fait que l'index de <emphasis>cette</emphasis>
+clé était peut-être corrompu (à cause d'un bug de &postgres;),
+et qu'il serait possible d'éviter ce problème en exécutant la
+commande suivante:</para>
<programlisting>
# reindex table _slonyschema.sl_log_1;
@@ -1624,8 +1628,8 @@
<para> Au moins dans une occasion cette solution s'est révélée efficace, alors cela sera dommage de ne pas suivre l'exemple.</para>
</answer>
-<answer> <para> Ce problème s'est avéré comme un bug dans &postgres; par opposition à un autre dans &slony1;. La version 7.4.8 avait intégré deux solutions qui permettent de résoudre ce cas. Or si vous avez un noyau de &postgres; antérieur à 7.4.8,
-vous devriez migrer d'abord pour éviter l'erreur.
+<answer> <para> Ce problème s'est avéré être un bug dans &postgres; plutot qu'un bug dans &slony1;. La version 7.4.8 a intégré deux solutions qui permettent de résoudre ce cas. Donc si vous avez un noyau de &postgres; antérieur à 7.4.8,
+vous devriez migrer pour éviter l'erreur.
</para>
</answer>
</qandaentry>
@@ -1633,12 +1637,12 @@
<application>pg_dump</application>, et Slony
s'arrête soudainement</para></question>
-<answer><para>Ouf. Ce qui se passe dans ce cas est à cause d'un conflit entre:
+<answer><para>Aïe. Ce qui se passe ici est un conflit entre:
<itemizedlist>
-<listitem><para> <application>pg_dump</application>, qui sort un <command>AccessShareLock</command> pour toutes les tables de la base, y compris celle de &slony1; et</para></listitem>
+<listitem><para> <application>pg_dump</application>, qui pose un verrou <command>AccessShareLock</command> sur toutes les tables de la base, y compris celle de &slony1; et</para></listitem>
-<listitem><para> Une synchronisation de &slony1; qui veut saisir
+<listitem><para> Un événement SYNC de &slony1; qui veut poser un verrou
<command>AccessExclusiveLock</command> sur la table <xref
linkend="table.sl-event"/>.</para></listitem> </itemizedlist></para>
@@ -1648,10 +1652,10 @@
select "_slonyschema".createEvent('_slonyschema, 'SYNC', NULL);
</screen></para>
-<para>(vous pouvez voir ceci dans<envar>pg_stat_activity</envar>, si votre paramètre d'affichage des requête est positionné à vrai dans
+<para>(vous pouvez voir ceci dans la vue <envar>pg_stat_activity</envar>, si l'affichage des requête est activé dans
<filename>postgresql.conf</filename>)</para>
-<para>L'interrogation encours qui cause ce verrous vient de la fonction <function>Slony_I_ClusterStatus()</function>, que vous trouverez dans
+<para>La requête qui demandece verrou vient de la fonction <function>Slony_I_ClusterStatus()</function>, que vous trouverez dans
<filename>slony1_funcs.c</filename>, localisé dans un bloc de code qui est :
<programlisting>
@@ -1660,9 +1664,9 @@
SELECT currval('%s.sl_event_seq');
</programlisting></para>
-<para>Le <command>VERROUS</command> se poste à ce moment et dure jusqu'à ce que
-<command>pg_dump</command> (ou le temps que les verrous bloquent les accès à <xref linkend="table.sl-event"/>)
-se términe.</para>
+<para>La demande de <command>VERROU</command> va donc attendre et
+durer jusqu'à ce que <command>pg_dump</command> (un autre programme ayant un verrou d'accès sur <xref linkend="table.sl-event"/>)
+se termine.</para>
<para>Chaque lecture touchant
<xref linkend="table.sl-event"/> sera bloqué derrière les appels à
@@ -1671,25 +1675,26 @@
<para>Les réponses à cette question sont multiples:
<itemizedlist>
-<listitem><para> Faire spécifier à <application>pg_dump</application> d'exporter le schéma en utilisant l'option <option>--schema=whatever</option>, et ne pas essayer d'exporter le schéma du cluster entièrement.</para></listitem>
+<listitem><para> Indiquer explicitement à <application>pg_dump</application>
+les schémas qu'il doit exporter en utilisant l'option <option>--schema=whatever</option>, et ne pas essayer d'exporter le schéma du cluster.</para></listitem>
-<listitem><para> Il sera utile aussi d'ajouter une option
-<option>--exclude-schema</option> à
-<application>pg_dump</application> afin d'exclure le schéma du cluster de &slony1;. A rêver que dans 8.2...</para></listitem>
+<listitem><para> Il sera utile aussi d'avoir une option
+<option>--exclude-schema</option> dans
+<application>pg_dump</application> afin d'exclure le schéma du cluster de &slony1;. Pourquoi pas dans 8.2...</para></listitem>
-<listitem><para>Notez que 1.0.5 utilise des verrous plus précis et moins exclusifs qui soulage ce problème.</para></listitem>
+<listitem><para>Notez que la version 1.0.5 utilise des verrous plus précis et moins exclusifs qui évitent ce problème.</para></listitem>
</itemizedlist></para>
</answer></qandaentry>
</qandadiv>
-<qandadiv id="faqoddities"> <title> &slony1; FAQ: Singularité des vulnérabilité dans Slony-I </title>
-<qandaentry><question><para> Que se produit à propos des règles et des déclencheurs pour des tables répliquées par
+<qandadiv id="faqoddities"> <title> &slony1; FAQ: Bizareries et modifications dans Slony-I </title>
+<qandaentry><question><para> Que se produit-il avec les règles et les déclencheurs pour ls tables répliquées par
&slony1;?</para>
</question>
-<answer><para> Premièrement regardons comment elle est gérée
-<emphasis>l'absence</emphasis> de gestion spécifique de la commande Slonik<xref
+<answer><para> Premièrement regardons comment ceci est géré
+<emphasis>en dehors</emphasis> du cas spécifique de la commande Slonik<xref
linkend="stmtstoretrigger"/>. </para>
<para> La fonction <xref
@@ -1698,42 +1703,43 @@
<itemizedlist>
-<listitem><para> Sur le noeud maître, ceci implique l'ajout d'un déclencheur
-qui utilise la fonction <xref linkend="function.logtrigger"/> à la table.</para>
+<listitem><para> Sur le noeud maître, ceci implique l'ajout sur la table d'un déclencheur
+qui utilise la fonction <xref linkend="function.logtrigger"/>.</para>
<para> Le déclencheur a pour action d'enregistrer, toutes les mises à jours dans
la table <xref linkend="table.sl-log-1"/> de &slony1;.
</para></listitem>
-<listitem><para> Sur un noeud d'abonné, répliquer une table, revient à désactiver les déclencheurs,
-puis, via un déclencheur, de restreindre le droit d'accès en écriture sur celle-ci en
+<listitem><para> Sur un noeud d'abonné, ceci revient à désactiver les déclencheurs et les règles,
+puis, via un déclencheur, de refuser le droit d'accès en écriture sur celle-ci en
utilisant la fonction <function>denyAccess()</function>.</para>
-<para> Jusqu'à la version 1.1 (et peut-être avant), le
+<para> Jusqu'à la version 1.1 (et peut-être après), la
<quote>désactivation</quote> est faite en modifiant
+la valeur de <envar>tgrelid</envar> dans les tables
<envar>pg_trigger</envar> ou <envar>pg_rewrite</envar>
-<envar>tgrelid</envar> en pointant l'identifiant OID sur
-la <quote>clé primaire</quote> de l'index du catalogue, plutôt qu'une action directe sur la table
-elle-même.</para></listitem>
+ en pointant l'identifiant OID sur
+la <quote>clé primaire</quote> de l'index du catalogue, plutôt que
+sur la table elle-même.</para></listitem>
</itemizedlist>
-<para> Un effet secondaire quelque part malheureu de ces actions sur les règles et les déclencheurs
-donne un effet de les <quote>piétiner</quote>. Dans la mesure où les règles et les déclencheurs sont toujours là,
+<para> Un effet secondaire malheureux est que cette gestion des règles et des déclencheurs a pour effet de les <quote>piétiner</quote>.
+Les règles et les déclencheurs sont toujours là,
mais ne plus correctement attachés à leurs tables. Si vous faite un <command>pg_dump</command> sur
-<quote>le noeud d'abonné</quote>, il ne trouvera pas les contraintes ni les déclencheur, et surtout il ne s'attend pas
-à les voir associés à un indexe.</para>
+<quote>le noeud d'abonné</quote>, il ne trouvera pas les règles ni les déclencheurs, et puisqu' il ne s'attend pas
+à les voir associés à un index.</para>
</answer>
<answer> <para> Maintenant observer comment <xref linkend="stmtstoretrigger"/>
entre en jeu.</para>
-<para> Mettez simplement cette commande pour que
-&slony1; restore les déclencheurs :
-<function>alterTableRestore(table id)</function>, qui restaure l'identifiant OID
-de la table dans <envar>pg_trigger</envar> ou
-<envar>pg_rewrite</envar> <envar>tgrelid</envar> sur le noeud affecté.</para></answer>
+<para> Pour simplifier, cette commande permet de restaurer les déclencheurs
+avec la fonction <function>alterTableRestore(table id)</function>,
+ qui restaure l'identifiant OID
+de la table dans la colonne <envar>tgrelid</envar> de <envar>pg_trigger</envar> ou
+<envar>pg_rewrite</envar> sur le noeud affecté.</para></answer>
<answer><para> Ceci implique que le jour où vous souhaitez lancer une sauvegarde directement
sur un abonné, vous devrez reprendre le schéma depuis un noeud d'origine. Clairement il faudra faire : </para>
@@ -1746,8 +1752,9 @@
</answer>
</qandaentry>
-<qandaentry> <question> <para> J'essaie de demander <xref
-linkend="stmtddlscript"/> ou <xref linkend="stmtmoveset"/>, et trouves
+<!-- todo -->
+<qandaentry> <question> <para> J'ai essayé les commandes <xref
+linkend="stmtddlscript"/> ou <xref linkend="stmtmoveset"/>, et trouvé
les messages suivants sur l'un des abonnés :</para>
<screen>
@@ -1758,44 +1765,45 @@
</question>
<answer> <para> La difficulté semble venir du fait que
-vous ajouter un déclencheur à une table dont le nom rentre en conflit,
-avec le déclencheur que &slony1; cache. </para>
+vous avez ajouté des déclencheurs sur des tables dont le nom rentre en conflit,
+avec les déclencheurs que &slony1; a caché. </para>
-<para> &slony1; cache des déclencheurs (sauf ceux marqués comme <quote>unhidden</quote>
+<para> &slony1; cache des déclencheurs (sauf ceux marqués comme <quote>visibles</quote>
via <xref linkend="stmtstoretrigger"/>) en les attachant à la clé primaire de leur table.
-Dans le cas d'une clef étrangère, d'autre déclencheurs sont rajoutés afin de garantir la cohérence des données.
-Il est complètement inutile des les lancer depuis un abonné, ainsi ces déclencheurs doivent être provoquer
-depuis le noeud d'origine. En revanche, les déclencheurs de type
-<quote>cache invalidation</quote> sont ceux que vous devrez lancer depuis l'abonné.</para>
+Dans le cas d'un déclencheur pour clef étrangère, ou d'autres déclencheurs de cohérence des données,
+il est complètement inutile de les placer sur un abonnné,
+au contraire ces déclencheurs doivent être mis en place
+sur le noeud d'origine. En revanche, les déclencheurs de type
+<quote>invalidation de cache</quote> peuvent être placés sur l'abonné.</para>
<para> La <emphasis>bonne manière</emphasis> de manipuler ce genre de déclencheurs est d'utiliser
<xref linkend="stmtstoretrigger"/>, qui indique à
-&slony1; de ne pas désactiver des déclencheurs. </para> </answer>
+&slony1; de ne pas désactiver le déclencheur. </para> </answer>
-<answer> <para> Mais il peut y avoir quelques DBA intrépides, qui vont assumer individuellement ce travail on
-installant les déclencheur à la main sur l'abonné, et donc capable de créer ce genre de situation. Que faire?
+<answer> <para> Mais il peut y avoir quelques DBAs intrépides, qui vont assumer individuellement ce travail en
+installant les déclencheur à la main sur l'abonné, et cela mène généralement créer ce genre de situation. Que faire ? Que faire ?
</para>
<para> La réponse est assez simple : Retirez le déclencheur
-<quote>spécifique</quote> sur l'abonné avant de dérouler la restauration.
+<quote>spécifique</quote> sur l'abonné avant que slony tente de les
+restaurer.
Dans le meilleur des cas, si le DBA est intrépide et réactif, il aurait fait cela
<emphasis>avant</emphasis> que le message ait le temps d'arriver. </para>
-<para> Si le DBA n'est pas intrépide, la réponse serait de se connecter au noeud
-offensé, et de supprimer la version <quote>visible</quote> du déclencheur utilisant l'ordre
+<para> Si le DBA n'est pas intrépide, il faut se connecter au noeud
+qui pose problème, et de supprimer la version <quote>visible</quote> du déclencheur utilisant l'ordre
<acronym>SQL</acronym> <command>DROP
TRIGGER</command>. Ceci permet à l'évènement de se dérouler.
Si l'évènement était <xref linkend="stmtddlscript"/>, alors notre
-<quote>pas-tellement-intrépide </quote> DBA devra ajouter le trigger à la main,
-ou, s'il y a plus de sagesse, de les réactiver avec
+<quote>pas-tellement-intrépide </quote> DBA devra remettre en place le déclencheur à la main, ou, s'il a plus de sagesse, il les réactivera avec
<xref linkend="stmtstoretrigger"/>.</para>
</answer>
</qandaentry>
<qandaentry id="neededexecddl">
-<question> <para> Comportement - tous les noeuds d'abonné, ainsi que le noeud maître,
-commence à se planter, crachant le message d'erreur suivant dans le journal,
+<question> <para> Le comportement : tous les noeuds abonné commencent
+ à tomber et ont le message d'erreur suivant dans le journal,
(lorsque j'ai rencontré ce problème, il y avait une longue requête SQL devant chaque message ):</para>
<screen>
@@ -1804,20 +1812,22 @@
</screen>
</question>
-<answer> <para> Cause: you have likely issued <command>alter
-table</command> statements directly on the databases instead of using
-the slonik <xref linkend="stmtddlscript"/> command.</para>
+<answer> <para> La cause : vous avez probablement effectué
+un <command>alter table</command> directement sur la
+base au lieu d'utiliser la commande slonik
+<xref linkend="stmtddlscript"/>.</para>
<para>La solution consiste à remettre le trigger sur la table affectée,
-et de corriger les données afférentes dans <xref linkend="table.sl-log-1"/> by hand.</para>
+et de corriger à la main les données afférentes dans <xref linkend="table.sl-log-1"/>.</para>
<itemizedlist>
-<listitem><para> Vous avez besoin d'extraire du journal soit de slon, soit
-du &postgres; l'ordre sql exact qui a causé l'anomalie.</para></listitem>
+<listitem><para> A partir des journaux de slon ou de &postgres;,
+vous devrez identifier la requête sql exacte qui a causé l'anomalie.</para></listitem>
-<listitem><para> Vous avez besoin de corriger le déclencheur Slony-defined dans la table
-en question. Ceci peut se faire à l'aide de la procédure suivante :</para>
+<listitem><para> Vous avez besoin de réparer les déclencheurs
+définis par Slony dans la table en question.
+Ceci peut se faire à l'aide de la procédure suivante :</para>
<screen>
BEGIN;
@@ -1827,10 +1837,12 @@
COMMIT;
</screen>
-<para>Ensuite vous avez besoin de sélectionner les enregistrements dans <xref
-linkend="table.sl-log-1"/> qui sont incohérent pour les corriger. Il faudra ensuite arrêter
-les processes de Slon pour l'ensemble des noeuds excepté celui du maître;
-de cette manière vous évitez que l'erreur se propage immédiatement à travers tous les noeuds.</para>
+<para>Ensuite vous devez trouver les enregistrements dans <xref
+linkend="table.sl-log-1"/> qui sont incohérents et les corriger.
+Il sera préférable d'arrêter les démons Slon
+pour l'ensemble des noeuds excepté celui du maître;
+de cette manière, si vous faites une erreur,elle ne se propagera
+pas immédiatement sur tous les noeuds abonnés.</para>
<para> Voici un exemple:</para>
@@ -1876,7 +1888,8 @@
<qandaentry>
<question><para> Le noeud numéro 1 a été supprimé via <xref
-linkend="stmtdropnode"/>, et le &lslon; d'un des noeuds fait cracher le message
+linkend="stmtdropnode"/>, et le &lslon; d'un autre noeud
+plante systématiquement avec le message
d'erreurs suivant:</para>
<screen>
@@ -1894,28 +1907,32 @@
DEBUG1 syncThread: thread done
</screen>
-<para> Evidemment une demande de <xref linkend="stmtstorelisten"/> n'avait pas encore
-été propagé avant que le noeud 1 soit éliminé.</para></question>
+<para> Il semble évident qu'un appel à <xref linkend="stmtstorelisten"/> n'avait pas encore été propagé avant que le noeud 1
+soit éliminé.</para></question>
-<answer id="eventsurgery"><para> Ceci indique le cas où vous avez besoin de
-<quote>opération chirurgicale</quote> sur l'un ou plusieurs noeuds.
-Un évènement<command>STORE_LISTEN</command> demeure sans réponse lorsqu'il veut
-ajouter un port d'écoute qui <emphasis>ne peut pas</emphasis> être satisfait car
-le noeud 1 ainsi que tous les éléments indiquant ce noeud sont disparus.</para>
+<answer id="eventsurgery"><para> Ceci illustre le cas où vous avez besoin de
+réaliser <quote>opération chirurgicale</quote> sur un ou plusieurs noeuds.
+Un évènement<command>STORE_LISTEN</command> demeure sans réponse
+alors qu'il veut
+ajouter une voie d'écoute qui <emphasis>ne peut pas</emphasis>
+être crée car le noeud 1 ainsi que toutes les voies vers le
+noeud 1 ont disparus.</para>
-<para> Supposons que pour la démonstration, les noeuds encore en place
-soient le 2 et le 3, ainsi le rapport d'erreur est remonté au noeud 3.</para>
+<para> Supposons, pour la démonstration, que les noeuds encore en place soient le 2 et le 3, ainsi le rapport d'erreur est remonté au noeud 3.</para>
-<para> cela implique que l'évènement se généré sur le noeud 2, comme il ne peut être sur le
-noeud 3, si il n'a pas été traité avec succès. La manière la plus facile à faire face à cette situation,
-est, de supprimer sur le noeud offensé, les données dans <xref linkend="table.sl-event"/> relatives au noeud 2.
-Vous vous connectez à la base du noeud 2, et à l'aide de Sql suivant, de chercher l'évènement
-<command>STORE_LISTEN</command>:</para>
+<para> cela implique que l'évènement est stocké sur le noeud 2,
+puisqu'il ne peut pas être sur le noeud 3, vu qu'il n'a pas été
+traité avec succès. La manière la plus facile à faire face à
+cette situation,
+est, de supprimer sur la ligne erronées dans
+ <xref linkend="table.sl-event"/> sur lenoeud 2.
+Vous vous connectez à la base du noeud 2, et vous recherchez
+ l'évènement <command>STORE_LISTEN</command>:</para>
<para> <command> select * from sl_event where ev_type =
'STORE_LISTEN';</command></para>
-<para> L'ordre peut ramener plusieurs lignes, mais ne en supprimer que la partie nécessaire.</para>
+<para> La requête peut ramener plusieurs lignes, mais ne supprimez que la partie nécessaire.</para>
<screen>
-# begin; -- Don't straight delete them; open a transaction so you can respond to OOPS
@@ -1928,12 +1945,12 @@
COMMIT
</screen>
-<para> La prochaine fois que <application>slon</application> pour le noeud 3 redémarre,
-il ne trouvera plus le <quote>souffrant</quote> évènement
-<command>STORE_LISTEN</command>, et la réplication peur se poursuivre.
-(Vous pouvez par contre voir surgir un vieil évènement enregistré qui ne soit plus en phase
-avec la configuration existante...) </para></answer>
+<para> La prochaine fois que le <application>slon</application> du noeud 3 va démarrer, il ne trouvera plus l' évènement
+<command>STORE_LISTEN</command> <quote>erroné</quote>, et la réplication pourra se poursuivre.
+( Cependnat vous pourrez ensuite voir surgir un vieil évènement
+enregistré qui fait référence à une configuration qui n'existe plus...) </para></answer>
+
</qandaentry>
</qandadiv>
Plus d'informations sur la liste de diffusion Trad