[Trad] [svn:pgfr] r1310 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Dim 26 Avr 23:48:10 CEST 2009
Author: daamien
Date: 2009-04-26 23:48:10 +0200 (Sun, 26 Apr 2009)
New Revision: 1310
Modified:
traduc/trunk/slony/faq.xml
Log:
Relecture FAQ (33%)
Modified: traduc/trunk/slony/faq.xml
===================================================================
--- traduc/trunk/slony/faq.xml 2009-04-26 21:32:49 UTC (rev 1309)
+++ traduc/trunk/slony/faq.xml 2009-04-26 21:48:10 UTC (rev 1310)
@@ -7,7 +7,7 @@
<qandaset>
<indexterm><primary>Foire Aux Questions de &slony1;</primary></indexterm>
-<qandadiv id="faqcompiling"><title> &slony1; FAQ: Monter et Installer &slony1; </title>
+<qandadiv id="faqcompiling"><title> &slony1; FAQ: Compiler et Installer &slony1; </title>
<qandaentry>
@@ -34,8 +34,6 @@
<listitem><para> &slony1; la version 1.0.5 et ultérieur nécessite d'avoir une version complètement configurées des sources de &postgres;, afin de recompiler
&slony1;.</para>
-<!-- TODO -->
-
<para> <emphasis>Heureusement </emphasis> vous pouvez adapter la configuration pour qu'elle corresponde à la configuration utilisée nativement par la paquet d'origine, en vérifiant la
version de &postgres; avec la commande
<command> pg_config --configure</command>. </para> </listitem>
@@ -122,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>
+<!--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>
@@ -222,9 +220,7 @@
<para> Ceci arrive avec &postgres; 8.2.5, ce qui est nettement plus récent que la version 7.3. </para>
</question>
-<answer> <para> La fonction <application>configure</application> est à la recherche du symbole PQunescapeBytea, elle compile un petit programme qu'il l'appele et
-vérifie la compilation se passe bien. Dans la ligne de commande <command>gcc</command>,
-elle utilise <command>-lpq</command> pour chercher la librairie. </para>
+<answer> <para> La fonction <application>configure</application> est à la recherche du symbole PQunescapeBytea, elle compile un petit programme qu'il l'appele et vérifie la compilation se passe bien. Dans la ligne de commande <command>gcc</command>, elle utilise <command>-lpq</command> pour chercher la librairie. </para>
<para> Malheureusement, ce paquetage n'a pas de lien symbolique, reliant <filename>/usr/lib64/libpq.so</filename> à
@@ -544,23 +540,20 @@
si vous n'y aller pas tuer à la main les processus &postgres;
.</para>
-<TODO>
+<!--TODO-->
<para> Il y a un autre cas qui pourrait causer l'ennui; quand
-&lslon; administrant son noeud d'attachement n'est pas en cours d'exécution
-,aucun évènement <command>SYNC</command> s'exécute sur ce même serveur. Si le &lslon;
- arrêté pour une longue durée, et que quelques chose du genre <xref linkend="gensync"/> n'est pas encours,
-vous pouvez vous retrouvez avec <emphasis>un énorme<command>SYNC</command></emphasis> à effectuer
-lorsque vous vous apprêtez à réaliser une sauvegarde. Ceci est vrai seulement si &lslon; est en arrêt pendant une période
-assez longue; alors que un arrêt de quelques seconds ne génère pas de problème.</para> </answer>
+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>
</qandaentry>
<qandaentry>
<question><para> Y a-t-il des risques pour ce faire ? Quels en 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 quelques moments un &lslon;
-ou peut-être même durant un cycle<emphasis>all</emphasis> de &lslon;s. </para> </answer>
+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>
</qandaentry>
</qandadiv>
@@ -570,8 +563,7 @@
<question><para>Slonik tombe en erreur - ne peut pas charger les 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 à
-:
+<para> Lorsque j'exécute un simple script de configuration, j'obtiens un message similaire à :
<command>
stdin:64: PGRES_FATAL_ERROR load '$libdir/xxid'; - ERROR: LOAD:
@@ -580,158 +572,116 @@
<answer><para> Evidemment, vous n'avez pas accès à la librairie
<filename>xxid.so</filename> dans le répertoire <envar>$libdir</envar>
-où l'instance &postgres; est en usage. Notez que le composant &slony1;doit être installé sur le noyau du &postgres;
-pour <emphasis>chacun des noeud</emphasis> et pas seulement sur le noeud d'origine.</para>
+que l'instance &postgres; utilise. Notez que les composants &slony1; doivent être installés avec le noyau du &postgres;
+sur <emphasis>chacun des noeuds</emphasis> et pas seulement sur le noeud d'origine.</para>
-<para>Cela peut également venir du fait d'une disparité entre les binaires
-du noyau &postgres; et celui du noyau de &slony1;. Si vous avez manuellement compilé &slony1;
-vous même, sur une machine où il y a plusieurs noyau de
-&postgres; <quote>se trouvant autour,</quote> il est possible
-que les binaires slon ou lslonik demande de charger une librairie qui n'est pas accessible
-actuellement dans les répertoires du noyau de &postgres; gérant le cluster.</para>
+<para>Cela peut également venir du fait d'une disparité entre les binaires du noyau &postgres; et celui du noyau de &slony1;. Si vous avez manuellement compilé &slony1; par vous-même, sur une machine où il y a plusieurs versions de &postgres;, il est possible que les binaires slon ou lslonik demande de charger une librairie qui n'est pas accessible dans les répertoires des librairies de la version de &postgres; utilisée.</para>
-<para>Court et concis: Ceci indique un besoin de <quote>auditer</quote>
-quel mode d'installation de &postgres; et de &slony1; vous avez en place sur vos machines.
-Malheureusement,n'importe quelle incompatibilité peut faire remonter ce genre
-de soucis. Voir aussi<link linkend="threadsafety">
-sécurité des thread </link> à propos de la gestion des thread sur Solaris.
-...</para>
+<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 sera plus simple si vous aviez un seul noyau 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.</para>
-Si vous avez une installation multiple,
-vous devrez vous assurez de la compatibilité de la bonne
-versions de &slony1; associé à la bonne version du noyau de
-&postgres;. </answer></qandaentry>
+<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,
+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'essai 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;
-alors confirmation, il ne faudra pas utiliser un "-"
-dans le nom.</para>
+<answer><para> &slony1; utilise les même règles de nommage que &postgres;, donc il ne faudra 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>
+<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>
</answer>
</qandaentry>
<qandaentry>
-<question><para>La commande ps affiche le mot de passe en claire</para>
+<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,
peut voir le mot de passe qui a été fourni à la ligne de commande.</para></question>
-<answer> <para>Conservez vous mot de passe en dehors de la configuration Slony, en les mettant dans
-des fichiers <filename>$(HOME)/.pgpass.</filename></para>
+<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>Sommaire de questions posées sur namespace
+<question><para>Nom du namespace dans les indexes
<programlisting>
set add table (set id = 1, origin = 1, id = 27,
- full qualified name = 'nspace.some_table',
- key = 'key_on_whatever',
- comment = 'Table some_table in namespace nspace with a candidate primary key');
+ full qualified name = 'nspace.ma_table',
+ key = 'clef_sur_une_colonne',
+ comment = 'une table ma_table dans le namespace nspace avec une clef primaire');
</programlisting></para></question>
<answer><para> Si vous avez <command> key =
-'nspace.key_on_whatever'</command> la demande
-<emphasis>echoura</emphasis>.</para>
+'nspace.clef_sur_une_colonne'</command> la demande
+<emphasis>échoura</emphasis>.</para>
</answer></qandaentry>
<qandaentry>
-<question> <para> La réplication a été retardée, et il semble que les interrogations pour restituer des données
-depuis <xref linkend="table.sl-log-1"/>/<xref
-linkend="table.sl-log-2"/> prennent beaucoup de temps en indiquant quelques demande de
-<command>SYNC</command>s. </para>
+<question> <para> La réplication est retardée, et il semble que les requetes 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>
-<answer> <para> Jusqu'à la version 1.1.1, la table <xref
-linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/>,possédait seulement un index, et si plusieurs jeu de réplication
-se mettaient en route en même temps, quelques colonnes dans l'indexe n'était pas très discriminent pour la manière d'accès.
+<answer> <para> Jusqu'à la version 1.1.1, les tables <xref
+linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/>,possédaient seulement un index, et lorsque il y avait plusieurs ensembles de réplication, quelques colonnes dans l'index n'était pas assez très discriminantes.
Si l'index ne contient pas la colonne<function> log_xid</function>, il est conseillé de l'ajouter. Voir le script
-<filename>slony1_base.sql</filename> pour regarder la manière de créer un indexe.
+<filename>slony1_base.sql</filename> pour regarder la manière de créer cet index.
</para>
</answer>
</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 ?
-Aurai-je à la recréer en dehors de la réplication ?</para>
+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 de
-clef primaire, mais actuellement c'est ainsi et on espère une gestion intégrée et transparente prochainement</para>.
+<answer><para> Affirmatif, c'est un scénario qui 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> Supposez que vous souhaiter renommer une colonne, comme dans uns script sql, on utiliserais la
+<para> Supposons que vous souhaiter renommez une colonne, avec la
commande DDL suivante<command> alter table accounts alter column aid rename to cid; </command> Ceci
-permet de renommer la colonne dans la table; elle permet de manière
-<emphasis>transparente</emphasis> de effectuer la mise à jour dans clef primaire qui contient la colonne en question.
-Le résultat est que ce genre de changement s'effectue simultanément sur les différents composants, du noeud.</para>
+permet de renommer la colonne dans la table; elle permet de mettre à jour <emphasis>simultanément</emphasis> l'index de la clef primaire. Le résultat est que ce genre de changement s'effectue simultanément sur un noeud donné.</para>
-<para> Dans l' <emphasis>ideal</emphasis> et pour bien faire les choses
-il aurait fallu utiliser <xref linkend="stmtddlscript"/> pour déployer la modification
-en étant sur que le bon changement s'applique aux bons noeuds.</para>
+<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> Pour la clarté des choses, tant que la modification commence par la partie répliquée et bien avant les abonnés,
-il n'y aura pas de cassure irrémédiable. Se retrouver avec quelques évènements de
-<command>SYNC</command> qui n'incluent pas la table sur laquelle il y a la modification, n'est pas un problème car ils vont se dérouler
-sans difficulté... Par contre si le changement est signalé d'abord par un abonné, alors
-point that the first update to the table is drawn in by a subscriber,
-<emphasis>ce</emphasis> sera le point de départ pour que
-<command>SYNC</command> tombe en erreur, puisque le fournisseur indiquera une
-<quote>nouvelle</quote> colonne alors que l'abonné connait toujours
-ses <quote>anciens</quote> formats. En appliquant la modification à postériori chez l'abonné, la commande
-<command>SYNC</command>, peut retrouver le
-<quote>nouveau</quote> nom de colonne et fonctionner sans plantage .
+<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
+<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>
<qandaentry id="v72upgrade">
-<question> <para> J'ai un &postgres; version 7.2 que je souhaite
-<emphasis>vraiment, vraiment</emphasis> employer avec &slony1; Que faut-il faire pour une migration en
-version 8.2 ? Quel est l'implication pour récupérer &slony1; afin de les exploiter ensemble?</para>
+<question> <para> J'ai un &postgres; version 7.2 et je souhaite
+<emphasis>vraiment</emphasis> utiliser &slony1; le migrer en
+version 8.0. Que faut-il faire pour que &slony1; fonctionne ?</para>
</question>
-<answer> <para> Voici l'écrit d'un certain Rod Taylor sur le sujet ...
+<answer> <para> Voici Rod Taylor écrit sur le sujet ...
</para>
<para> Voici ce dont approximativement vous avez besoin:</para>
<itemizedlist>
-<listitem><para>Prendre les formulaire 7.3 et de mes copier en 7.2 -- ou bien de
- mettre en dur 7.3 dans vos formulaire </para></listitem>
-<listitem><para>Supprimer toute trace de schémas dans le code sql de vos formulaires.
- Sommairement je remplace "." par "-". </para></listitem>
-<listitem><para> Le bloc de travail relatif aux models de données XID ainsi qu’aux fonctions.
- Par exemple, Slony crée des CASTs pour the xid en xxid et vice versa -- mais
- la 7.2 ne peut pas crée de nouveau casts et dans ce cas vous êtes obligé de le modifier à la main.
- Je rappelle la création d'une classe d'opérateur ainsi que l'édition de certaines fonctions. </para></listitem>
-<listitem><para>sl_log_1 aura de grave problème 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>
-<listitem><para> Ne pas s' embeter à essayer de travailler en séquence. Faites les à la main
- en utilisant pg_dump et grep. </para></listitem>
+<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>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>
+<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 implémenter la 7.2 de manière artisanale
-du moins, forcer slony à travailler sans les schémas dans la nouvelle version versions de &postgres;
-ainsi le dialogue entre les deux peut être établi.
+<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
+, ou vous modifiez slony pour qu'il fonctionne sans les schémas avec les nouvelles versions de &postgres; afin qu'ils puissent
+dialoguer.
</para>
<para> Juste après le déroulement de la procédure de migration de 7.2 vers 7.4,
-on peut désinstaller la version bidouillée de Slony (à la main encore pour la majeur partie), et démarrer la migration
-de 7.2 à 7.4 sur les différentes machines en utilisant un Slony standard.
-Ceci permettant de s'assurer sur la fiabilité d'un catalogue système qui avait subi des changement manuels.
+on peut désinstaller la version bidouillée de Slony (à la main encore pour la majeure partie), et démarrer la migration
+de 7.2 à 7.4 sur les différentes machines en utilisant un Slony standard. Ceci afin de s'assurer qu'on ne conserve pas les catalogues systèmes qui ont subi des changements manuels.
</para>
-<para> Tout cela pour dire, que nous migrons quelque centaine de GO de données,
-de 7.2 a 7.4 en espace de 30 minutes. (contre 48 heures auparavant annoncées myeneant un dump et
-restore) sans pertes de données.
+<para> Ceci étant dit, nous avons migré quelques centaines de Go de données,
+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
Plus d'informations sur la liste de diffusion Trad