[Trad] [svn:pgfr] r1360 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Sam 18 Juil 10:12:24 CEST 2009
Author: daamien
Date: 2009-07-18 10:12:24 +0200 (Sat, 18 Jul 2009)
New Revision: 1360
Modified:
traduc/trunk/slony/faq.xml
Log:
relecture faq (50%)
Modified: traduc/trunk/slony/faq.xml
===================================================================
--- traduc/trunk/slony/faq.xml 2009-06-28 08:46:42 UTC (rev 1359)
+++ traduc/trunk/slony/faq.xml 2009-07-18 08:12:24 UTC (rev 1360)
@@ -120,7 +120,7 @@
<answer><para>Sur AIX et Solaris (et probablement sur d'autre OS),
&slony1; <emphasis>et &postgres;</emphasis> doivent être compilés avec l'option <option>--enable-thread-safety</option> . Le message ci-dessus arrive lorsque la compilation
de &postgres; n'a pas fait appel à cette option.</para>
-<!--TODO-->
+
<para>Le disfonctionnement ici vient du fait que le libc (indépendant des threads) et libpq
(basés sur les threads) utilisent des emplacements de mémoire différente pour les codes d'erreur, c'est qui fait échouer les requêtes.</para>
@@ -537,30 +537,34 @@
vous pouvez découvrir que les connexions de la base de données sont laissées <command>disponible en transaction</command> ("idle in transaction").
Ceci peut peut arriver si les connexions réseaux sont supprimées sans que &lslon; ni la base en ait pris connaissance
.Dans ce cas vous pouvez découvrir que des connexions <quote>zombies</quote> traînent encore durant deux long heures
-si vous n'y aller pas tuer à la main les processus &postgres;
+si vous n'aller pas tuer à la main les processus &postgres;
.</para>
-<!--TODO-->
+<para> Il y existe un autre cas qui peut poser problème : quand
-<para> Il y a un autre cas qui pourrait causer l'ennui; quand
-un processus &lslon; administre le noeud origine ne fonctionne pas,
-aucun évènement <command>SYNC</command> ne s'exécute sur ce noeud. Si le &lslon; reste arrêté pendant une longue durée, et qu'aucun processus de type <xref linkend="gensync"/> n'est pas en cours, alors vous pouvez vous retrouvez avec <emphasis>un énorme <command>SYNC</command></emphasis> à effectuer
-lorsque le processus &lslon; du noeud origine sera relancé. toutefois ceci est vrai seulement si &lslon; est en arrêt pendant une période
-assez longue; un arrêt de quelques seconds ne génère pas de problèmes.</para> </answer>
+le processus &lslon; qui administre le noeud origine ne fonctionne pas,
+aucun évènement <command>SYNC</command> ne s'exécute sur ce noeud.
+Si le &lslon; reste arrêté pendant une longue durée, et qu'aucun processus de type
+<xref linkend="gensync"/> n'est en cours, alors vous pouvez vous retrouvez avec
+<emphasis>un énorme <command>SYNC</command></emphasis> à effectuer
+lorsque le processus &lslon; du noeud origine sera relancé.
+Toutefois ceci est vrai seulement si &lslon; est en arrêt pendant une période
+assez longue; un arrêt de quelques secondes ne génère pas de problèmes.</para> </answer>
</qandaentry>
<qandaentry>
-<question><para> Y a-t-il des risques pour ce faire ? Quels en sont les avantages ?</para></question>
+<question><para> Y a-t-il des risques lorsque l'on arrête &lslon; ? Quels sont les avantages ?</para></question>
-<answer><para> En bref, si votre <command>COPY_SET</command> prend environ 18h pour s'exécuter
-finalement, ce n'est pas un grand sacrifice d'arrêter un &lslon; pendant quelques instants ou peut-être même <emphasis>tous</emphasis> les &lslon;s durant un cycle. </para> </answer>
+<answer><para> En bref, si un <command>COPY_SET</command> qui dure 18h n'est pas en cours d'exécution
+, alors ce n'est pas un grand sacrifice d'arrêter un &lslon; pendant quelques instants, ni même
+de relancer <emphasis>tous</emphasis> les &lslon;s. </para> </answer>
</qandaentry>
</qandadiv>
<qandadiv id="faqconfiguration"> <title> &slony1; FAQ: Problèmes de configuration </title>
<qandaentry>
-<question><para>Slonik tombe en erreur - ne peut pas charger les librairies &postgres; -
+<question><para>Slonik tombe échoue lors du chargement des librairies &postgres; :
<command>PGRES_FATAL_ERROR load '$libdir/xxid';</command></para>
<para> Lorsque j'exécute un simple script de configuration, j'obtiens un message similaire à :
@@ -580,14 +584,14 @@
<para>En deux mots : Ceci indique que vous devez <quote>auditer</quote>
comment ont été installés les instances &postgres; et de &slony1; qui sont en place sur la machine. Malheureusement, n'importe quelle incompatibilité peut faire remonter ce genre d'erreur. Voir aussi <link linkend="threadsafety"> sécurité des threads </link> à propos de la gestion des threads sur Solaris.</para>
-<para> La situation est plus simple si vous avez une seule version de &postgres; installé par serveur; dans ce cas il n'y aura pas d' <quote>incompatibilité de chemins</quote> dans lequel les composants de &slony1; sont installés. Si vous avez une installation multiple,
+<para> La situation est plus simple si vous avez une seule version de &postgres; installée par serveur; dans ce cas il n'y aura pas d' <quote>incompatibilité de chemins</quote> là ou les composants de &slony1; sont installés. Si vous avez une installation multiple,
vous devrez vous assurez que la bonne version de &slony1; est associée
à la bonne version du noyau de &postgres;. </para></answer></qandaentry>
<qandaentry>
-<question> <para>J'essai de créer un cluster dont le nom contient un "-". Cela ne marche pas.</para></question>
+<question> <para>J'essaie de créer un cluster dont le nom contient un "-". Cela ne marche pas.</para></question>
-<answer><para> &slony1; utilise les même règles de nommage que &postgres;, donc il ne faudra pas utiliser un "-"
+<answer><para> &slony1; utilise les mêmes règles de nommage que &postgres;, donc vous ne devrize pas utiliser un "-"
dans les identifiants.</para>
<para> Vous pouvez tenter de mettre des simples <quote>quotes</quote> pour l'identifiant, mais vous allez vous exposer à des soucis, qui pourront surgir à tout moment.</para>
@@ -597,14 +601,14 @@
<qandaentry>
<question><para>La commande ps affiche le mot de passe en clair</para>
-<para> Si je lance une commande <command>ps</command>, tout le monde,
+<para> Avec la commande <command>ps</command>, tout le monde,
peut voir le mot de passe qui a été fourni à la ligne de commande.</para></question>
<answer> <para>Conservez le mot de passe en dehors de la configuration Slony, en les mettant dans le fichier <filename>$(HOME)/.pgpass.</filename></para>
</answer></qandaentry>
<qandaentry>
-<question><para>Nom du namespace dans les indexes
+<question><para>Indexes dont le nom contient le namespace
<programlisting>
set add table (set id = 1, origin = 1, id = 27,
@@ -614,12 +618,13 @@
</programlisting></para></question>
<answer><para> Si vous avez <command> key =
-'nspace.clef_sur_une_colonne'</command> la demande
+'nspace.clef_sur_une_colonne'</command> la requête
<emphasis>échoura</emphasis>.</para>
</answer></qandaentry>
<qandaentry>
-<question> <para> La réplication est retardée, et il semble que les requetes sur les tables <xref linkend="table.sl-log-1"/>/<xref
+<question> <para> La réplication est retardée, et il semble que les requêtes sur les tables
+<xref linkend="table.sl-log-1"/>/<xref
linkend="table.sl-log-2"/> prennent beaucoup de temps alors qu'il n'y a que quelques événements <command>SYNC</command>s. </para>
</question>
@@ -632,11 +637,11 @@
</qandaentry>
<qandaentry><question> <para> J'ai besoin de renommer une colonne qui figure dans la clef
-primaire pour l'une de mes tables répliquées. L'opération s'avère un peu dangereuse, est-ce vrai ?
+primaire pour l'une de mes tables répliquées. L'opération est un peu dangereuse, n'est-ce pas ?
Je dois retirer la table de la réplication puis la replacer, c'est bien ça ?</para>
</question>
-<answer><para> Affirmatif, c'est un scénario qui fonctionne proprement. &slony1; fait un usage intensif des
+<answer><para> En fait, cette opération fonctionne proprement. &slony1; fait un usage intensif des
clefs primaires, mais en pratique ce type d'opération peut se faire de manière transparente.</para>.
<para> Supposons que vous souhaiter renommez une colonne, avec la
@@ -645,7 +650,7 @@
<para> Dans l' <emphasis>ideal</emphasis> et pour bien faire les choses il aurait fallu utiliser <xref linkend="stmtddlscript"/> pour déployer la modification au moment sur chaque noeud.</para>
-<para> Toutefois ce n'est pas forcément nécessaire. Tant que la modification est appliquée sur le noeud origine avant d'^etre effectuée sur les abonnés, il n'y aura pas de cassure irrémédiable. Certains évènements <command>SYNC</command> qui n'incluent pas la table sur laquelle il y a la modification, pourront fonctionner sans problème... Par contre lorsqu'une mise à jour de la table est effectué sur un abonné, alors les événements <command>SYNC</command> vont échouer, puisque le fournisseur indiquera une <quote>nouvelle</quote> colonne alors que l'abonné connait toujours les <quote>anciennes</quote>. Dès que l'on appliquera la modification de la clef chez l'abonné, les évenements
+<para> Toutefois ce n'est pas forcément nécessaire. Tant que la modification est appliquée sur le noeud origine avant d'être effectuée sur les abonnés, il n'y aura pas de cassure irrémédiable. Certains évènements <command>SYNC</command> qui n'incluent pas la table sur laquelle il y a la modification, pourront fonctionner sans problème... Par contre lorsqu'une mise à jour de la table est effectué sur un abonné, alors les événements <command>SYNC</command> vont échouer, puisque le fournisseur indiquera une <quote>nouvelle</quote> colonne alors que l'abonné connait toujours les <quote>anciennes</quote>. Dès que l'on appliquera la modification de la clef chez l'abonné, les évenements
<command>SYNC</command> seront retraités et le <quote>nouveau</quote> nom de colonne sera présent et tout fonctionnera sans plantage .
</para> </answer></qandaentry>
@@ -660,12 +665,12 @@
<para> Voici ce dont approximativement vous avez besoin:</para>
<itemizedlist>
-<listitem><para>Prendre les templates 7.3 et de les copier en 7.2 -- ou bien mettre en dur 7.3 dans vos templates </para></listitem>
+<listitem><para>Prendre les templates 7.3 et de les copier en 7.2 -- ou bien écrire en dur la version de vos templates </para></listitem>
<listitem><para>Supprimer toute trace de schémas dans le code sql de vos templates. Concrètement j'ai remplacé les "." par "-". </para></listitem>
<listitem><para> Pas mal de travaux sur les types et fonctins XID.
-Par exemple, Slony crée des CASTs pour la conversion xid vers xxid et vice versa -- mais la 7.2 ne peut pas créer de nouveau casts et dans ce cas vous êtes obligé de le modifier à la main.
-Je rappelle avoir créé une classe d'opérateur et modifié certaines fonctions. </para></listitem>
-<listitem><para>sl_log_1 aura de graves problèmes de performance quelque soit le volume de données. Ceci exige qu'un certain nombre d'indexe soient positionnés pour optimiser les interrogations en 7.2, 7.3 et supérieur. </para></listitem>
+Par exemple, Slony crée des CASTs pour la conversion xid vers xxid et vice versa -- mais la 7.2 ne peut pas créer de nouveaux casts et dans ce cas vous êtes obligé de le modifier à la main.
+Je me rappelle avoir créé une classe d'opérateur et modifié certaines fonctions. </para></listitem>
+<listitem><para>sl_log_1 aura de graves problèmes de performance quelque soit le volume de données. Ceci exige qu'un certain nombre d'index soient positionnés pour optimiser les interrogations en 7.2, 7.3 et supérieur. </para></listitem>
<listitem><para> Ne pas s'embeter à essayer de faire fonctionner les séquences. Faites les à la main en utilisant pg_dump et grep. </para></listitem>
</itemizedlist>
<para> Bien sûr, une fois que ces pre-requis terminés, on n'est pas encore compatible avec le Slony standard. Ainsi ou bien, vous devez au moins modifier la version 7.2 de manière moins artisanale
@@ -681,38 +686,38 @@
de 7.2 à 7.4 avec une coupure de service de 30 minutes. (contre 48 heures de dump/restore) et sans pertes de données.
</para>
</answer>
-<!--todo-->
-<answer> <para> Ceci vous dresse un éventail assez laid qualifié de
-<quote>bidouille</quote> qu'il faut admettre entrer dans le périmètre de production.
-Si quelqu'un est intéressé pour le transformer en
-<quote>tâche de production</quote>, il y aura un sens dans ce cas de s'appuyer sur
+
+<answer> <para> Ceci vous dresse un éventail assez laid des
+<quote>bidouilles</quote> qu'il faut faire entrer dans le périmètre de production.
+Si quelqu'un est intéressé pour
+<quote>industrialiser</quote> cette tache, il vaut mieux s'appuyer sur
&slony1; en version 1.0, avec un maître mot de ne
<emphasis>pas</emphasis> essayer de le rendre pérenne, étant donnée sa durée de vie limitée.</para>
<para> Vous devriez seulement adapter cette solution que si vous êtes à l'aise avec
-&postgres; et &slony1; et que de mettre la main au code ne vous fait pas peur. </para> </answer>
+&postgres; et &slony1; et si mettre la main au code ne vous fait pas peur. </para> </answer>
</qandaentry>
<qandaentry>
-<question> <para> J'avais un réseau <quote>pas performant</quote> qui m'obligeais à utiliser
- <xref linkend="stmtfailover"/> un basculement sur un noeud secondaire.
+<question> <para> J'ai subit une <quote>avarie réseau</quote> qui m'a obligé à utiliser
+ <xref linkend="stmtfailover"/> pour basculer sur un noeud secondaire.
Le plantage n'était pas causé par un problème de corruption de donnée venant du disque,
-Pourquoi serais-je obligé de reconstruire depuis le début, le noeud planté ? </para></question>
+Pourquoi serais-je obligé de reconstruire le noeud planté ? </para></question>
<answer><para> Le rôle de <xref linkend="stmtfailover"/> est d'
<emphasis>abandonner</emphasis> le noeud planté, et par conséquence il n'a plus de
charge générée par l'activité de &slony1;. Plus le temps passe plus le serveur planté se désynchronise.</para></answer>
-<answer><para> L'<emphasis>énorme</emphasis> problème afin de restaurer le serveur planté,
-est qu'il peut contenir des mises à jours qui n'ont pas eu le temps de se propager endors.
+<answer><para> L'<emphasis>énorme</emphasis> problème pour restaurer le serveur planté,
+est qu'il peut contenir des mises à jours qui n'ont pas eu le temps de se propager en dehors.
Vous ne pouvez pas non plus les rejouer, car elles vont être conflictuelles, car à moitié en place.
En tout cas vous avez une sorte de corruption <quote>logique</quote>de donnée, qui n'est jamais causée par une erreur disque.
dite <quote>physique.</quote>
</para></answer>
-<answer><para> Comme cela a été abordé en <xref linkend="failover"/>, utiliser <xref
-linkend="stmtfailover"/> revient à accepter comme <emphasis>dernier
-ressort</emphasis> tant qu'il implique d'abandonner le noeud d'origine pour cette corruption.</para></answer>
+<answer><para> Comme cela a été abordé dans la section <xref linkend="failover"/>, <xref
+linkend="stmtfailover"/> doit être utilisé en <emphasis>dernier
+recourt</emphasis> car cela implique d'abandonner le noeud d'origine pour cette corruption.</para></answer>
</qandaentry>
@@ -724,8 +729,8 @@
DETAIL: Key (sub_provider,sub_receiver)=(1,501) is not present in table "sl_path".
</screen>
-<para> Par la suite l'erreur est suivie par un ensemble d'<xref
-linkend="slon"/> arrêt: de syncs:</para>
+<para> Par la suite l'erreur est suivie par un ensemble de SYNCs en échec
+tandis que <xref linkend="slon"/> s'arrête :</para>
<screen>
DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
@@ -742,19 +747,19 @@
</question>
-<answer><para> Si vous regardez les journaux de &lslon; à l'arrêt avec des erreurs due à cet effet
-<emphasis>d'arrêt</emphasis>, vous auriez besoin de revenir en arrière en ignorant une partie de
-ces journalisation,
-<emphasis>en attendant</emphasis> après le redémarrage du serveur en erreur de trouver la cause d'origine.</para></answer>
+<answer><para> Si vous constatez qu'un &lslon; s'arrête et que le jounal de log indique que
+des événements ont été ignorés, vous devez remonter dans le journal
+<emphasis>avant</emphasis> que ces erreurs apparaissent, pour trouver des indications
+sur l'origine du problème.</para></answer>
<answer><para> Dans ce cas particulier, l'erreur est due à la commande
<xref linkend="stmtstorepath"/> qui n'est pas encore répercutée sur le noeud 4 en attendant la propagation
de <xref linkend="stmtsubscribeset"/> command</para>
-<para>Ceci démontre encore un autre exemple où l'approximatif ne devra pas prendre le dessus,
-et que on doit avec assurance vérifier le bon fonctionnement des choses
-<emphasis>avant</emphasis> de suggérer un changement de la configuration.
-</para></answer>
+<para>Cet exemple démontre à nouveau qu'il ne faut pas se précipiter;
+vous devez vous assurer que tout fonctionne correctement
+<emphasis>avant</emphasis> de poursuivre les changements de configuration.
+</para></answer>
</qandaentry>
@@ -766,10 +771,11 @@
Que puis-je faire? </para></question>
<answer><para> Vous avez besoin d'utiliser <xref linkend="stmtsubscribeset"/> afin de modifier les abonnements
- de ces serveurs abonnés, que leurs fournisseur <emphasis>sera</emphasis> indisponible durant une période maintenance.</para>
+ de ces serveurs abonnés et les réorienter vers un fournisseur qui <emphasis>sera</emphasis> disponible durant la période de maintenance.</para>
-<warning> <para> Que vous avez <emphasis>omis</emphasis> de faire <xref
-linkend="stmtunsubscribeset"/>; pour que vous soyez obligé de recommencer à rafraîchir les noeuds depuis le début.
+<warning> <para> Il <emphasis>ne faut pas</emphasis> faire <xref
+linkend="stmtunsubscribeset"/>; car vous seriez obligé de
+recharger toutes les données à partir de zéro.
</para></warning>
</answer>
@@ -777,16 +783,16 @@
<qandaentry>
<question><para> Après la notification d'un abonnement auprès
-<emphasis>d'un autre</emphasis> serveur fournisseur, la réplication tombe en erreur, et commençant des messages d'erreurs
-avec :</para>
+<emphasis>d'un autre</emphasis> serveur fournisseur, la réplication tombe en panne, et affiche des messages d'erreurs
+du type :</para>
<screen>
ERROR remoteWorkerThread_1: "begin transaction; set transaction isolation level serializable; lock table "_livesystem".sl_config_lock; select "_livesystem".enableSubscription(25506, 1, 501); notify "_livesystem_Event"; notify "_livesystem_Confirm"; insert into "_livesystem".sl_event (ev_origin, ev_seqno, ev_timestamp, ev_minxid, ev_maxxid, ev_xip, ev_type , ev_data1, ev_data2, ev_data3, ev_data4 ) values ('1', '4896546', '2005-01-23 16:08:55.037395', '1745281261', '1745281262', '', 'ENABLE_SUBSCRIPTION', '25506', '1', '501', 't'); insert into "_livesystem".sl_confirm (con_origin, con_received, con_seqno, con_timestamp) values (1, 4, '4896546', CURRENT_TIMESTAMP); commit transaction;" PGRES_FATAL_ERROR ERROR: insert or update on table "sl_subscribe" violates foreign key constraint "sl_subscribe-sl_path-ref"
DETAIL: Key (sub_provider,sub_receiver)=(1,501) is not present in table "sl_path".
</screen>
-<para> Ceci est suivi plus tard par une série d'erreur de syncs puisque le <xref
-linkend="slon"/> est à l'arrêt:
+<para> Ceci est suivi plus tard par une série d'erreur de syncs tandis que le <xref
+linkend="slon"/> s'arrête :
<screen>
DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
@@ -803,30 +809,29 @@
</para></question>
-<answer><para> Si lors d'un arrêt, vous voyez dans le journal d'un &lslon;
-<emphasis>des nouveaux évènements ignorés dus à l'arrêt</emphasis> ,
-c'est le cas parlant où il faut revenir une étape en arrière
-<emphasis>avant</emphasis> l'arrêt pour voir l'origine de l'erreur.
-</para></answer>
+<answer><para> Si vous constatez qu'un &lslon; s'arrête et que le jounal de log indique que
+des événements ont été ignorés, vous devez remonter dans le journal
+<emphasis>avant</emphasis> que ces erreurs apparaissent, pour trouver des indications
+sur l'origine du problème.</para></answer>
-<answer><para> Dans ce cas particulier, le problème était que certain
- <xref linkend="stmtstorepath"/> commandes n'ont pas été transmises aux noeud 4 avant <xref linkend="stmtsubscribeset"/>
- la commande soit propagée. </para>
+<answer><para> Dans ce cas particulier, le problème était que certaines commandes
+ <xref linkend="stmtstorepath"/> n'ont pas été transmises aux noeud 4 avant que
+le commande <xref linkend="stmtsubscribeset"/> ne soit propagée. </para>
<para>C'est encore un exemple où il ne faut pas hâtivement modifier les choses
-;vous devrez avec certitude, constater le disfonctionnement
+; vous devez être sur que tout fonctionne bien
<emphasis>avant</emphasis> de faire de nouveau changement de configuration.
</para></answer>
</qandaentry>
<qandaentry>
-<question> <para> Est-ce que dans une configuration globale, l'ordre dans lequel, on traite les tables
-est important ?</para>
+<question> <para> Est-ce que l'ordre dans une ensemble de réplication est important ?</para>
</question>
-<answer> <para> La plupart de temps il ne l'est pas. Vous devrez adapter un ordre selon lequel
-les tables <quote>maîtres</quote> sont mises à jour avant celles de <quote>détails</quote>
-en fonction de la relation de clef étrangère qui les relie; ceci ne sera <emphasis>pas exigé</emphasis> si sur le noeud abonné,
+<answer> <para> La plupart de temps il ne l'est pas. On pourrait imaginer qu'il faille
+déclarer les tables <quote>mères</quote> avant leurs <quote>filles</quote>
+en fonction des relations de clefs étrangères qui les relient;
+mais ce n'est <emphasis>pas nécessaire</emphasis> si sur le noeud abonné,
on a pris le soin, de désactiver les déclencheurs.
</para>
</answer>
Plus d'informations sur la liste de diffusion Trad