[Trad] [svn:pgfr] r1238 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Mar 10 Fév 23:41:58 CET 2009
Author: gleu
Date: 2009-02-10 23:41:58 +0100 (Tue, 10 Feb 2009)
New Revision: 1238
Modified:
traduc/trunk/slony/installation.xml
traduc/trunk/slony/intro.xml
traduc/trunk/slony/prerequisites.xml
Log:
Relecture, ?\195?\169tape 4.
Modified: traduc/trunk/slony/installation.xml
===================================================================
--- traduc/trunk/slony/installation.xml 2009-02-02 17:40:15 UTC (rev 1237)
+++ traduc/trunk/slony/installation.xml 2009-02-10 22:41:58 UTC (rev 1238)
@@ -6,342 +6,393 @@
<sect1 id="installation">
<title>Installation de &slony1;</title>
-
<indexterm><primary>instructions d'installation</primary></indexterm>
-<note> <para>Pour les utilisateurs de &windows; : À moins que
- vous comptiez modifier le code de &slony1;, il est fortement
- recommandé de télécharger et d'installer une version
- binaire précompilée et passer directement à la section
- configuration ci-dessous. Vous trouverez les liens et les
- binaires officiels sur <ulink url="http://pgfoundry.org/projects/slony1/">
-le site pgFoundry de &slony1;</ulink>, notamment la version version 1.2.0. </para>
+<note>
+ <para>
+ Pour les utilisateurs de &windows; : à moins de modifier le code de
+ &slony1;, il est fortement recommandé de télécharger et d'installer une
+ version binaire précompilée et de passer directement à la section
+ configuration ci-dessous. Vous trouverez les liens et les binaires
+ officiels sur le <ulink url="http://pgfoundry.org/projects/slony1/">site de
+ &slony1;</ulink>, notamment la version 1.2.0.
+ </para>
-<para> Il existe également des binaires RPM disponibles pour les versions récentes
- de &slony1; et de &postgres;.
-</para>
+ <para>
+ Il existe également des binaires RPM disponibles pour les versions récentes
+ de &slony1; et de &postgres;.
+ </para>
</note>
-<warning><para> Si vous utilisez &slony1; pour remplacer une version
- antérieure de &postgres; par une version récente, ou si vous
- souhaitez une version issue du CVS, en dehors du contexte de la
- sortie d'une version majeure, alors préparez vous à compiler
- à la fois &postgres; et &slony1; à partir des sources.
- Cette section est rédigé en supposant que vous lu cet avertissement...</para>
+<warning>
+ <para>
+ Si vous utilisez &slony1; pour remplacer une version antérieure de
+ &postgres; par une version récente, ou si vous souhaitez une version issue
+ du CVS, en dehors du contexte de la sortie d'une version majeure, alors
+ préparez-vous à compiler à la fois &postgres; et &slony1; à partir des
+ sources. Cette section est rédigée en supposant que vous avez lu cet
+ avertissement...
+ </para>
</warning>
-<para>Vous devez avoir obtenu les sources de &slony1; à l'étape précédante.
- Décompressez le paquet.</para>
+<para>
+ Vous devez avoir obtenu les sources de &slony1; à l'étape précédente.
+ Décompressez le paquet.
+</para>
-<screen>
-gunzip slony.tar.gz;
-tar xf slony.tar
-</screen>
+<screen>gunzip slony.tar.gz;
+tar xf slony.tar</screen>
-<para> Ceci va créer un répertoire contenant les sources dans votre répertoire courant.
- Déplacez-vous dans ce répertoire et rester y pendant toute la procédure d'installation.
-.</para>
+<para>
+ Ceci va créer un répertoire contenant les sources dans votre répertoire
+ courant. Déplacez-vous dans ce répertoire et restez-y pendant toute la
+ procédure d'installation.
+</para>
<sect2>
<title>Version courte</title>
+<indexterm><primary>installation : version courte</primary></indexterm>
-<indexterm><primary> installation : version courte</primary></indexterm>
-
<para>
-<screen>
-PGMAIN=/usr/local/pgsql746-freebsd-2005-04-01 \
+<screen>PGMAIN=/usr/local/pgsql746-freebsd-2005-04-01 \
./configure \
--with-pgconfigdir=$PGMAIN/bin
gmake all; gmake install
</screen>
</para>
+
</sect2>
<sect2>
<title>Configuration</title>
+<indexterm><primary>instructions de configuration</primary></indexterm>
-<indexterm><primary>Instructions de configuration</primary></indexterm>
+<para>
+ Normalement, &slony1; doit être compilé et installé avec le compte Unix
+ &postgres;. La cible de l'installation doit être identique à l'installation
+ &postgres; existante, notamment parce que plusieurs composants de &slony1;
+ sont des bibliothèques et des scripts SQL qui doivent être dans les
+ répertoires <filename>lib</filename> et <filename>share</filename> de
+ &slony1;.
+</para>
-<para> Normalement &slony1; doit être compilé et installé avec le compte
- Unix &postgres;. La cible de l'installation doit être identique à
- l'installation &postgres; existante, notamment parce que plusieurs
- composants de &slony1; sont des librairies et des scripts SQL
- qui doivent être dans les répertoires <filename>lib</filename> et
-<filename>share</filename> &slony1;. </para>
+<para>
+ La première étape de la procédure d'installation est de configurer l'arbre
+ des sources pour votre système. Ceci se fait en lançant le script
+ <application>configure</application>. Dans les versions précédentes,
+ <application>configure</application> devait savoir où se trouvait l'arbre
+ des sources de &postgres;, ce qui était renseigné avec l'option
+ <option>--with-pgsourcetree=</option>. À partir de la version 1.1, ceci
+ n'est plus nécessaire car &slony1; inclut dans son propre code applicatif
+ certaines parties nécessaire pour faciliter la porbabilité entre les
+ différentes plates-formes. Désormais, il suffit de faire référence à des
+ composants de &postgres; qui font partie de l'installation. Ainsi, &slony1;
+ est configuré en pointant vers les différentes répertoire de &postgres; :
+ binaires, bibliothèques et fichiers d'en-tête. Pour une liste complète de ces
+ options, utilisez la commande <command>./configure --help</command>.
+</para>
-<para>La première étape de la procédure d'installation est de configurer
- l'arbre des sources pour votre système. Ceci se fait en
- lançant le script <application>configure</application>. Dans les
- versions précédantes, <application>configure</application> devait
- savoir où se trouvait l'arbre des sources de &postgres;, ce
- qui était renseigné avec l'option <option>--with-pgsourcetree=</option>.
- À partir de la version 1.1, ceci n'est plus nécessaire, car
- &slony1; inclut dans son propre code applicatif certaines parties
- nécessaire pour la probabilité entre les différentes plates-formes.
- Désormais il suffit de faire référence à des composants de &postgres;
- qui font partie de l'installation. Ainsi, &slony1; est configuré
- en pointant vers les différentes répertoire de &postgres; :
- library, binary, et include. Pour une liste complète de ces options,
- utiliser la commande <command>./configure --help</command>.</para>
+<para>
+ <emphasis>Normalement</emphasis>, il est suffisant d'exécuter
+ <command>configure<option>--with-pgconfigdir=/un/certain/chemin</option></command>,
+ où <filename>/un/certain/chemin</filename> est l'emplacement où se situe le
+ programme <application>pg_config</application> de &postgres;. À partir de
+ <application>pg_config</application>, le script <filename>configure</filename>
+ peut déterminer les divers emplacements des composants &postgres;, ce qui
+ permet de déduire où installer les composants essentiels de &slony1;.
+</para>
-<para> <emphasis>Normalement,</emphasis> il est suffisant d'exécuter
- <command>configure <option>--with-pgconfigdir=/some/path/somewhere</option></command>,
-où <filename>/some/path/somewhere</filename> est l'emplacement ou se situe le
-programme <application>pg_config</application> de &postgres;.
-À partir de <application>pg_config</application>, le script
-<filename>configure</filename> peut déterminer les divers emplacements
-où les composants &postgres; se trouvent, ce qui permet de déduire où
-les composants essentiels de &slony1; doivent être installé.</para>
+<para>
+ Sur certaines plate-formes (AIX et Solaris sont connus pour cela mais pas
+ Linux), la compilation de &postgres; doit être expressement configuré avec
+ l'option <command>--enable-thread-safety</command> pour fournir les
+ bibliothèques clients correctes.
+</para>
-<para>Sur certaines plate-formes (AIX et Solaris sont connus pour cela;
-mais pas Linux ), la compilation de &postgres; doit être expressement
-configuré avec l'option <command>--enable-thread-safety</command>
-pour fournir les librairies clients correctes. </para>
+<para>
+ La version 8 de &postgres; installe les fichiers d'en-tête
+ <command>#include</command> par défaut. Avec les versions 7.4 et antérieures,
+ vous devez vous assurer que la compilation inclut la commande <command>make
+ install-all-headers</command>, sinon les en-têtes du serveur ne seront pas
+ installés et &slony1; ne pourra pas être compilé.
+</para>
-<para> La version 8 de &postgres; installe les fichiers d'en-tête
- <command>#include</command> par défaut. Avec la version 7.4 et
- antérieures, vous devez vous assurez que la compilation inclue
- la commande <command>make install-all-headers</command>, sinon
- les en-tête du serveur ne seront pas installés, et &slony1;
- ne sera pas capable de compiler.</para>
-
-<para>Après avoir lancé configure, vous pouvez ouvrir le fichier
-<filename>Makefile.global</filename> pour vous assurer qu'il
-recherche tous les composants dans les bons emplacements.
+<para>
+ Après avoir lancé configure, vous pouvez ouvrir le fichier
+ <filename>Makefile.global</filename> pour vous assurer qu'il recherche tous
+ les composants dans les bons emplacements.
</para>
-
</sect2>
<sect2>
<title>Exemple</title>
-<para> Après avoir déterminé que l'instance &postgres; est installé dans
-<filename>/opt/dbs/pgsql746-aix-2005-04-01</filename>:</para>
+<para>
+ Après avoir déterminé que l'instance &postgres; est installé dans
+ <filename>/opt/dbs/pgsql746-aix-2005-04-01</filename> :
+</para>
-<screen>
-PGMAIN=/opt/dbs/pgsql746-aix-2005-04-01 \
+<screen>PGMAIN=/opt/dbs/pgsql746-aix-2005-04-01 \
./configure \
- --with-pgconfigdir=$PGMAIN/bin
-</screen>
+ --with-pgconfigdir=$PGMAIN/bin</screen>
-<para>Le script <application>configure</application> lancera de nombreux
-tests pour deviner les valeurs de différentes variables et tente de
-détecter certains particularités de votre système.
-&slony1; est connu pour avoir besoin d'une version modifiée de
-<application>libpq</application> sur des plate-formes spécifiques
-telles que Solaris2.X sur SPARC. Le correctif de la version
-7.4.2 de la libpq se trouvent à l'adresse <ulink id="threadpatch" url=
-"http://developer.postgresql.org/~wieck/slony1/download/threadsafe-libpq-742.diff.gz">
-http://developer.postgresql.org/~wieck/slony1/download/threadsafe-libpq-742.diff.gz
-</ulink> Des correctifs similaires peuvent compilés pour d'autres versions;
-voir l'entrée dans la FAQ intitulée <link linkend="threadsafety"> sécurité des threads
-</link>. </para>
+<para>
+ Le script <application>configure</application> lance de nombreux tests pour
+ deviner les valeurs des différentes variables et tente de détecter certaines
+ particularités de votre système. &slony1; est connu pour avoir besoin d'une
+ version modifiée de <application>libpq</application> sur des plate-formes
+ spécifiques telles que Solaris2.X sur SPARC. Le correctif de la version 7.4.2
+ de la libpq se trouvent à l'adresse <ulink id="threadpatch" url=
+ "http://developer.postgresql.org/~wieck/slony1/download/threadsafe-libpq-742.diff.gz">
+ http://developer.postgresql.org/~wieck/slony1/download/threadsafe-libpq-742.diff.gz
+ </ulink>. Des correctifs similaires peuvent être compilés pour d'autres
+ versions ; voir l'entrée dans la FAQ intitulée <link
+ linkend="threadsafety">sécurité des threads</link>.
+</para>
-<para> Pour une liste de toutes les options de configuration, lancer la commande
-<command>./configure --help</command>.</para>
+<para>
+ Pour une liste de toutes les options de configuration, lancez la commande
+ <command>./configure --help</command>.
+</para>
+
</sect2>
<sect2>
<title>Compilation</title>
-<para>Pour démarrer le processus de compilation, tapez :
+<para>
+ Pour démarrer le processus de compilation, tapez :
+ <screen>gmake all</screen>
+</para>
-<screen>
-gmake all
-</screen></para>
+<para>
+ Assurez d'utiliser GNU make ; sur les systèmes BSD, il est appelé
+ <application>gmake</application> ; sur Linux, GNU make est généralement
+ le <application>make</application> <quote>natif</quote>, ainsi le nom de la
+ commande que vous devez taper peut être <command>make</command> ou
+ <command>gmake</command>. Sur d'autres plate-formes, vous aurez peut-être
+ besoin de paquets supplémentaires ou même d'une installation complète de
+ GNU make. La compilation prend entre quelques secondes et deux minutes selon
+ la rapidité de votre matériel. La dernière ligne affichée devrait être :
+</para>
-<para> Assurez d'utiliser GNU make; sur les systèmes BSD, il est appelé
-<application>gmake</application>; sur Linux, GNU make est généralement
-le <application>make</application> <quote>natif</quote>, ainsi le
-nom de la commande que vous devez taper peut être <command>make</command> ou
-<command>gmake</command>. Sur d'autres plate-formes, vous aurez peut-être
-besoin de paquets supplémentaires ou même un installation complète de
-GNU make. La compilation prend entre quelques secondes et
-2 minutes selon la rapidité de votre matériel. La dernière ligne affichée
-devrait être :</para>
+<para>
+ <command>All of Slony-I is successfully made. Ready to install.</command>
+</para>
-<para> <command> All of Slony-I is successfully made. Ready to
-install. </command></para>
</sect2>
<sect2>
-<title> Installer &slony1; une fois compilé</title>
+<title>Installer &slony1; une fois compilé</title>
-<para> Pour installer &slony1;, tapez :
+<para>
+ Pour installer &slony1;, tapez :
+ <command>gmake install</command>
+</para>
-<command>
-gmake install
-</command></para>
+<para>
+ Ceci va installer les fichiers dans le répertoire d'installation de PostgreSQL
+ tel que spécifié par l'option <option>--prefix</option> de
+ <command>configure</command> utilisé lors de l'installation de &postgres;.
+ Assurez-vous que vous avez les droits adéquats pour écrire dans cet
+ emplacement. En général, vous devez être soit root ou l'utilisateur postgres.
+</para>
-<para>Ceci va installer les fichiers dans le répertoire d'installation
- de the PostgreSQL tel que spécifié par l'option <option>--prefix</option>
- de <command>configure</command> utilisé lors de l'installation de
- &postgres;. Assurez-vous que vous avez les permissions adéquates pour écrire
- dans cette emplacement. En général, vous devez être soit root ou l'utilisateur
- postgres.
+<para>
+ Voici la liste des fichiers principaux installés dans l'instance
+ PostgreSQL :
</para>
-<para>Voici la liste des fichiers principaux installés dans l'instance PostgreSQL :</para>
<itemizedlist>
-<listitem><para><filename> $bindir/slon</filename></para></listitem>
-<listitem><para><filename> $bindir/slonik</filename></para></listitem>
-<listitem><para><filename> $libdir/slony1_funcs$(DLSUFFIX)</filename></para></listitem>
-<listitem><para><filename> $libdir/xxid($DLSUFFIX)</filename></para></listitem>
-<listitem><para><filename> $datadir/slony1_base.sql</filename></para></listitem>
-<listitem><para><filename> $datadir/slony1_base.v73.sql</filename></para></listitem>
-<listitem><para><filename> $datadir/slony1_base.v74.sql</filename></para></listitem>
-<listitem><para><filename> $datadir/slony1_base.v80.sql</filename></para></listitem>
-<listitem><para><filename> $datadir/slony1_funcs.sql</filename></para></listitem>
-<listitem><para><filename> $datadir/slony1_funcs.v73.sql</filename></para></listitem>
-<listitem><para><filename> $datadir/slony1_funcs.v74.sql</filename></para></listitem>
-<listitem><para><filename> $datadir/slony1_funcs.v80.sql</filename></para></listitem>
+ <listitem><para><filename> $bindir/slon</filename></para></listitem>
+ <listitem><para><filename> $bindir/slonik</filename></para></listitem>
+ <listitem><para><filename> $libdir/slony1_funcs$(DLSUFFIX)</filename></para></listitem>
+ <listitem><para><filename> $libdir/xxid($DLSUFFIX)</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_base.sql</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_base.v73.sql</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_base.v74.sql</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_base.v80.sql</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_funcs.sql</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_funcs.v73.sql</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_funcs.v74.sql</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_funcs.v80.sql</filename></para></listitem>
</itemizedlist>
-<para> (Notez qu'au fur et à mesure des versions, la liste des fichiers spécifiques à
- une version va s'agrandir...) </para>
+<para>
+ (Notez qu'au fur et à mesure des versions, la liste des fichiers spécifiques
+ à une version va s'agrandir...)
+</para>
-<para>Les fichiers <filename>.sql</filename> ne sont pas encore complètement
- installés. Les versions 7.3, 7.4 et 8.0 des fichiers sont installés
- sur chaque systèmes, quelque soit la version de &postgres;.
- L'outil d'administration <xref linkend="slonik"/> effectue des substitutions
- d'espace de noms et de cluster dans ces fichiers, puis chargent les fichiers
- lors de la création d'un noeud de réplication. À cet instant, la base de donnée
- qui est initialisée peut être à distance ou utiliser une version différente
- de &postgres; par rapport à la version de l'hôte local.</para>
+<para>
+ Les fichiers <filename>.sql</filename> ne sont pas encore complètement
+ installés. Les versions 7.3, 7.4 et 8.0 des fichiers sont installés sur
+ chaque système, quelque soit la version de &postgres;. L'outil d'administration
+ <xref linkend="slonik"/> effectue des substitutions d'espace de noms et de
+ cluster dans ces fichiers, puis chargent les fichiers lors de la création d'un
+ nœud de réplication. À cet instant, la base de donnée qui est initialisée
+ peut être à distance ou utiliser une version différente de &postgres; par
+ rapport à la version de l'hôte local.
+</para>
-<para> Pour terminer, les deux objets partagés installés dans le répertoire
- <filename>$libdir</filename> doivent être installés sur chaque
- ordinateur qui va devenir un noeud &slony1;. ( D'autres composants
- peuvent être chargés à distance à partir des autres noeuds.) </para>
+<para>
+ Pour terminer, les deux objets partagés installés dans le répertoire
+ <filename>$libdir</filename> doivent être installés sur chaque ordinateur
+ qui va devenir un nœud &slony1; (d'autres composants peuvent être
+ chargés à distance à partir des autres nœuds.).
+</para>
</sect2>
-<sect2> <title> Compiler la documentation: Guide d'administration </title>
+<sect2>
+<title>Compiler la documentation : Guide d'administration</title>
+<indexterm><primary>compiler la documentation &slony1;</primary></indexterm>
-<indexterm><primary> compiler la documentation &slony1; </primary></indexterm>
+<para>
+ Le document que vous êtes en train de lire est un <quote>guide
+ d'administration</quote> très complet qui contient toute la sagesse
+ découverte lors de l'utilisation et la maintenance de &slony1;.</para>
-<para> Le document que vous êtes en train de lire est un <quote>guide d'administration</quote>
- très complet qui contient toute la sagesse découverte lors de l'utilisation
- et la maintenance de &slony1;.</para>
+<para>
+ Cette documentation est compilé uniquement si vous spécifiez l'option
+ <command>--with-docs</command>.
+</para>
-<para> Cette documentation est compilé uniquement si vous spécifiez l'option
- <command>--with-docs</command></para>
+<para>
+ Notez que vous pouvez rencontrer des difficultés pour compiler la
+ documentation sur les systèmes basés sur Red Hat à cause de la valeur NAMELEN
+ qui est trop faible. Havoc Pennington a déclaré ce bug au milieu de l'année
+ 2001, à l'époque de Red Hat 7.1 ; La société Red Hat Software a reconnu
+ ce bug mais il n'y a eu aucun progrès depuis. La seconde URL ci-dessous
+ indique qu'il y a eu des tentatives de correction en élevant la valeur de
+ NAMELEN dans une future version de Red Hat Enterprise Linux, mais cela n'est
+ pas le cas en 2008. La distribution Fedora Core 4 devrait avoir corrigé ce
+ problème plus tôt.
+</para>
-<para> Notez que vous pouvez rencontrer des difficultés pour compiler
- la documentation sur les systèmes basés sur Red Hat à cause
- de la valeut NAMELEN qui est trop faible.
- Havoc Pennington a déclaré ce bug au milieu de l'année 2001, à l'époque
- de Red Hat 7.1; La société Red Hat Software a reconnu ce bug,
- mais il n'y a eu aucun progrès depuis. La seconde URL ci-dessous
- indique qu'il y a eu des tentatives de correction en élevant
- la valeur de NAMELEN dans une future version de Red Hat Enterprise Linux,
- mais cela n'est pas le cas en 2008. La distribution Fedora Core 4
- devrait avoir corrigé ce problème plus tôt. </para>
+<para>
+ <ulink url="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36058">Bug
+ 36058</ulink>
+</para>
<para>
-<ulink url=
-"https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36058"> Bug
-36058 </ulink> </para>
+ <ulink url="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159382">Bug
+ 159382 (pour RHEL)</ulink>
+</para>
<para>
-<ulink url=
-"https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159382"> Bug
-159382 (For RHEL) </ulink> </para>
+ Une version pré-compilée du « Guide d'administration » est disponible soit
+ sous la forme de paquets d'archive séparés, soit dans le répertoire
+ <filename>doc/adminguide/prebuilt</filename>
+</para>
-<para>Une version pré-compilée du "guide de l'admin" est disponible
- soit sous la forme de paquets tarball séparés, ou dans le répertoire
-<filename>doc/adminguide/prebuilt</filename> </para>
+<para>
+ Voir le fichier <filename>INSTALL</filename> pour un contournement
+ du problème sous Fedora...
+</para>
-<para> Voir le fichier <filename>INSTALL</filename> pour un contournement
- du problème sous Fedora...</para>
-
</sect2>
<sect2>
-<title> Installer &slony1; à partir des RPMs</title>
+<title>Installer &slony1; à partir des RPM</title>
-<para> Même si &slony1; peut être compilé et exécuté sur
- la pluspart des distributions Linux, il est également possible
- d'installer &slony1; en utilisant des paquets binaires.
- L'équipe de développement de Slony ( NdT :"Slony Global Development Team")
- fournit des paquets RPMs et SRPMs officiels pour différentes versions
- de Red Hat et Fedora Core.</para>
+<para>
+ Même si &slony1; peut être compilé et exécuté sur la plupart des
+ distributions Linux, il est également possible d'installer &slony1; en
+ utilisant des paquets binaires. L'équipe de développement de Slony (NdT :
+ « Slony Global Development Team ») fournit des paquets RPM et SRPM
+ officiels pour différentes versions de Red Hat et Fedora Core.
+</para>
-<para>Les RPMs sont disponibles sur <ulink
-url="http://pgfoundry.org/projects/slony1/"> le site &slony1; sur pgFoundry.org
-</ulink>. Lisez le fichier <command> CURRENT_MAINTAINER</command> pour
-plus de détails sur les RPMs. Notez que ces RPMs rechercheront
-&postgres; tel qu'installé par RPM, donc si vous avez installé
-&postgres; à partir des sources, vous devez ignorer explicitement
-les dépendances liées à &postgres;.</para>
+<para>
+ Les RPM sont disponibles sur le <ulink
+ url="http://pgfoundry.org/projects/slony1/">site &slony1; sur pgFoundry.org
+ </ulink>. Lisez le fichier <command>CURRENT_MAINTAINER</command> pour
+ plus de détails sur les RPM. Notez que ces RPM rechercheront &postgres; tel
+ qu'installé par RPM, donc si vous avez installé &postgres; à partir des
+ sources, vous devez ignorer explicitement les dépendances liées à
+ &postgres;.
+</para>
-<para>Installer &slony1; à partir de ces RPMs est aussi facile
- qu'avec n'importe quel paquet RPM :</para>
+<para>
+ Installer &slony1; à partir de ces RPM est aussi facile qu'avec n'importe
+ quel paquet RPM :
+</para>
<screen>rpm -ivh postgresql-slony1-engine-....rpm</screen>
-<para>Si vous voulez mettre à jour une version antérieur, utilisez simplement
- la commande <command>rpm -Uvh</command>. Cependant n'oubliez pas de suivre
- la procédure habituelle de mise à jour.</para>
+<para>
+ Si vous voulez mettre à jour une version antérieure, utilisez simplement la
+ commande <command>rpm -Uvh</command>. Cependant, n'oubliez pas de suivre la
+ procédure habituelle de mise à jour.
+</para>
-<para>Le paquet RPM installe les fichiers à leur emplacements habituels.
- Les fichiers de configuration sont dans le répertoire <filename>/etc</filename>,
- les fichiers binaires sont installés dans <filename>/usr/bin</filename>,
- les librairies sont dans <filename>/usr/lib/pgsql</filename>, et enfin
- la documentation est située dans <filename>/usr/share/doc/postgresql-slony1-engine</filename>.
+<para>
+ Le paquet RPM installe les fichiers à leur emplacements habituels. Les
+ fichiers de configuration sont dans le répertoire <filename>/etc</filename>,
+ les fichiers binaires sont installés dans <filename>/usr/bin</filename>, les
+ bibliothèques sont dans <filename>/usr/lib/pgsql</filename> et enfin la
+ documentation est située dans <filename>/usr/share/doc/postgresql-slony1-engine</filename>.
</para>
</sect2>
<sect2>
-<title> Installer le service &slony1; sur &windows;</title>
-
+<title>Installer le service &slony1; sur &windows;</title>
<indexterm><primary>installation &slony1; sur &windows;</primary></indexterm>
-<para> Sur les systèmes &windows;, au lieu de lancer un démon <xref
-linkend="slon"/> par noeud, un service slon unique est installé
-et peut alors être contrôlé via le panneau de contrôle des <command>Services</command>,
-ou à partir de la console de commande en utilisant la commande
-<command>net</command>.</para>
+<para>
+ Sur les systèmes &windows;, au lieu de lancer un démon <xref
+ linkend="slon"/> par nœud, un service slon unique est installé et peut
+ alors être contrôlé via le panneau de contrôle des
+ <command>Services</command> ou à partir de la console de commande en
+ utilisant la commande <command>net</command>.
+</para>
-<screen>
-C:\Program Files\PostgreSQL\8.0\bin> slon -regservice my_slon
+<screen>C:\Program Files\PostgreSQL\8.0\bin> slon -regservice my_slon
Service registered.
Before you can run Slony, you must also register an engine!
WARNING! Service is registered to run as Local System. You are
encouraged to change this to a low privilege account to increase
-system security.
-</screen>
+system security.</screen>
-<para> Une fois que le service est installé, les noeuds individuels peuvent
- être configurés en enregistrant les fichiers de configuration auprès du service :
+<para>
+ Une fois que le service est installé, les nœuds individuels peuvent
+ être configurés en enregistrant les fichiers de configuration auprès du
+ service :
</para>
-<screen>
-C:\Program Files\PostgreSQL\8.0\bin> slon -addengine c:\node1.conf
-Engine added.
-</screen>
+<screen>C:\Program Files\PostgreSQL\8.0\bin> slon -addengine c:\node1.conf
+Engine added.</screen>
-<para>Les autres commandes sont équivoques : <command>slon -unregservice
+<para>
+ Les autres commandes sont équivoques : <command>slon -unregservice
<nom du service></command>, <command>slon -listengines
<nom du service></command> et <command>slon -delengine
-<nom du service> <config file></command>.</para>
+<nom du service> <config file></command>.
+</para>
-<para> Pour plus d'informations à propos de la version &windows;, vous pouvez
- consulter les pages suivantes : </para>
+<para>
+ Pour plus d'informations à propos de la version &windows;, vous pouvez
+ consulter les pages suivantes :
+</para>
<itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://developer.pgadmin.org/~hiroshi/Slony-I/">Exemple
+ d'installation de Slony-I sous Windows (en anglais)</ulink>
+ </para>
+ </listitem>
-<listitem><para> <ulink
-url="http://developer.pgadmin.org/~hiroshi/Slony-I/"> Exemple d'installation de Slony-I sous Windows (en anglais)
-</ulink> </para> </listitem>
-
-<listitem><para> <ulink url=
-"http://people.planetpostgresql.org/xzilla/index.php?/archives/200-Alpha-testing-Slony-on-win32-Crib-Notes.html">
-Notes rapides suite à des tests de Slony sous Windows par xzilla (en anglais) </ulink> </para> </listitem>
-
+ <listitem>
+ <para>
+ <ulink url="http://people.planetpostgresql.org/xzilla/index.php?/archives/200-Alpha-testing-Slony-on-win32-Crib-Notes.html">
+ Notes rapides suite à des tests de Slony sous Windows par xzilla (en
+ anglais)</ulink>
+ </para>
+ </listitem>
</itemizedlist>
</sect2>
Modified: traduc/trunk/slony/intro.xml
===================================================================
--- traduc/trunk/slony/intro.xml 2009-02-02 17:40:15 UTC (rev 1237)
+++ traduc/trunk/slony/intro.xml 2009-02-10 22:41:58 UTC (rev 1238)
@@ -6,322 +6,443 @@
<sect1 id="introduction">
<title>Introduction à &slony1;</title>
+<indexterm><primary>introduction à &slony1;</primary></indexterm>
-<indexterm><primary> introduction à &slony1; </primary></indexterm>
+<sect2> <title>Qu'est-ce que &slony1; ?</title>
-<sect2> <title>Qu'est ce que &slony1; ?</title>
+<para>
+ &slony1; est un système de réplication entre <quote>un maître et plusieurs
+ esclaves</quote> qui supporte les cascades et la promotion d'un esclave en
+ maître. Le schéma directeur du développement de &slony1; est la création
+ d'un système maître-esclave qui inclue les fonctionnalités nécessaires
+ pour répliquer de grandes bases de données avec un nombre raisonnable
+ d'esclaves. <quote>Raisonnable,</quote> dans ce contexte signifie une
+ douzaine de serveurs. Si le nombre de serveurs évolue au-delà de cette
+ limite, le coût des communications augmente de manière prohibitive et le
+ bénéfice d'avoir plusieurs serveurs diminue.
+</para>
-<para>&slony1; est système de réplication entre <quote>un maître et de multiple esclaves</quote>
-qui supporte les cascades et la promotion d'un esclave en maître.
-Le schéma directeur du développement de &slony1; est la création
-d'un système maître-esclave qui inclue les fonctionnalités nécessaire
-pour répliquer de grandes bases de données avec un nombre raisonnable
-d'esclaves. <quote>Raisonnable,</quote> dans ce contexte, signifie
-une douzaine de serveurs. Si le nombre de serveurs évolue au-delà de
-cette limite, le coût des communications augmentent de manière prohibitive,
-et le bénéfice d'avoir de multiple serveurs s'amenuise.</para>
+<para>
+ Voir la section <xref linkend="slonylistenercosts"/> pour une analyse plus
+ détaillée des coûts associés à l'augmentation du nombre de nœuds.
+</para>
-<para> Voir la section <xref linkend="slonylistenercosts"/> pour une
- analyse plus détaillées des coûts associés à l'augmentation du
- nombre de noeuds.</para>
+<para>
+ &slony1; est un système conçu pour les centres de données et pour les sites
+ de sauvegarde, où le fonctionnement des opérations est que tous les
+ nœuds sont disponibles en permanence, et où tous les nœuds peuvent
+ être sécurisés. Si vous avez des nœuds qui risquent régulièrement d'être
+ coupés du réseau, ou si la sécurité de vos nœuds ne peut pas être
+ garantie, &slony1; n'est probablement pas la solution de réplication idéale
+ pour vous.
+</para>
-<para> &slony1; est un système conçu pour les datacenters et sites de
- sauvegardes, où le fonctionnement des opérations est que tous les
- noeuds sont disponibles en permanence, et où tous les noeuds peuvent
- être sécurisés. Si vous avez des noeuds qui risquent régulièrement d'être
- coupés du réseau, ou si la sécurité de vos noeuds ne peut pas
- être garantie, &slony1; n'est probablement pas la solution de réplication
- idéale pour vous.</para>
+<para>
+ Voici notamment quelques exemples de cas où &slony1; ne sera probablement
+ pas adapté :
-<para> Voici notamment quelques exemples de cas où &slony1; ne sera probablement
- pas adapté :
+ <itemizedlist>
+ <listitem>
+ <para>
+ Les sites dont la connectivité est <quote>instable</quote>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ La réplication entre des nœuds qui ne sont pas toujours
+ interconnectés.
+ </para>
+ </listitem>
-<itemizedlist>
-<listitem><para> Les sites dont la connectivité est <quote>instable</quote>
-</para></listitem>
-<listitem><para> La réplication entre des noeuds qui ne sont pas toujours interconnectés</para></listitem>
+ <listitem>
+ <para>
+ Répliquer une base de tarification à partir d'un serveur central vers
+ l'équipe commerciale qui s'y connecte périodiquement pour en extraire
+ les mise à jour.
+ </para>
+ </listitem>
-<listitem><para> Répliquer une base de tarification à partir d'un serveur central vers
- l'équipe commerciale qui s'y connecte périodiquement pour en extraire les mise à jour.
- </para></listitem>
+ <listitem>
+ <para>
+ Les sites où les changements de configuration sont faits de manière
+ hasardeuse.
+ </para>
+ </listitem>
-<listitem><para> Les sites où les changements de configuration sont faits de
- manière hasardeuse.</para></listitem>
-
-<listitem><para> Un situation <quote>d'hébergement web</quote> où les
- utilisateurs peuvent de manière indépendante et arbitraire changer les
- schémas des données.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Une situation d'<quote>hébergement web</quote> où les utilisateurs
+ peuvent de manière indépendante et arbitraire changer les schémas des
+ données.
+ </para>
+ </listitem>
</itemizedlist>
</para>
-<para> Il existe une extension de <link linkend="logshipping"> log shipping par fichier</link>
- qui permet de regrouper les mises à jour dans des fichiers.
- Ainsi, les fichiers de mises à jours peuvent être distribués
- par différents moyens sans avoir à attendre d'accusé de réception
- entre les noeud fournisseur et les noeuds qui sont abonnés au
- <quote>log shipping</quote>. Le noeuds abonnés au <quote>Log
-shipping</quote> n'augmente pas les coûts de communication être
-les noeuds &slony1;.</para>
-<para> Mais &slony1;, ayant une seule origine par ensemble de données répliqué,
- n'est pas adapté pour effectuer de la réplication <emphasis>réellement</emphasis> asynchrone
- et multi-directionnelle. Pour celles et ceux qui recherche une
- <quote>réplication asynchrone multi-maîtres avec résolution des conflits</quote>
- telle que ce que fournit <productname>Lotus
-<trademark>Notes</trademark></productname> ou les protocoles de <quote>synchronisation</quote>
-présents sur les systèmes PalmOS, il est nécessaire de se tourner vers d'autres logiciels.
+<para>
+ Il existe une extension du <link linkend="logshipping">log shipping par
+ fichier</link> qui permet de regrouper les mises à jour dans des fichiers.
+ Ainsi, les fichiers de mises à jours peuvent être distribués par différents
+ moyens sans avoir à attendre d'accusé de réception entre le nœud
+ fournisseur et les nœuds qui sont abonnés au <quote>log
+ shipping</quote>. Les nœuds abonnés au <quote>log shipping</quote>
+ n'augmentent pas les coûts de communication entre les nœuds &slony1;.
+</para>
+
+<para>
+ Mais &slony1;, ayant une seule origine par ensemble de données répliqué,
+ n'est pas adapté pour effectuer de la réplication
+ <emphasis>réellement</emphasis> asynchrone et multi-directionnelle. Pour
+ celles et ceux qui recherchent une <quote>réplication asynchrone
+ multi-maîtres avec résolution des conflits</quote> telle que ce que fournit
+ <productname>Lotus <trademark>Notes</trademark></productname> ou les
+ protocoles de <quote>synchronisation</quote> présents sur les systèmes PalmOS,
+ il est nécessaire de se tourner vers d'autres logiciels.
</para>
-<para> Il existe également d'autres modèles de réplication qui ne sont pas sans avantages,
- mais qui permettent des scénarios de réplication <emphasis>différents</emphasis>
- de ce que &slony1; propose.</para>
+<para>
+ Il existe également d'autres modèles de réplication qui ne sont pas sans
+ avantages mais qui permettent des scénarios de réplication
+ <emphasis>différents</emphasis> de ce que &slony1; propose.
+</para>
</sect2>
-<sect2><title>Pourquoi proposer encore un autre système de réplication ?</title>
+<sect2>
+<title>Pourquoi proposer encore un autre système de réplication ?</title>
-<para>&slony1; est né de l'idée de créer un système de réplication qui ne soient
- pas lié à une version spécifique de &postgres;, pour qu'il puisse être lancé
- et arrêté sur une base existante sans besoin d'effectuer un cycle d'export/import
- des données.</para>
+<para>
+ &slony1; est né de l'idée de créer un système de réplication qui ne soit pas
+ lié à une version spécifique de &postgres;, pour qu'il puisse être lancé et
+ arrêté sur une base existante sans besoin d'effectuer un cycle d'export/import
+ des données.
+</para>
</sect2>
-<sect2><title> Ce que &slony1; n'est pas</title>
+<sect2>
+<title>Ce que &slony1; n'est pas</title>
<itemizedlist>
-<listitem><para>&slony1; n'est pas un système de gestion de réseau.</para></listitem>
+ <listitem>
+ <para>
+ &slony1; n'est pas un système de gestion de réseau.
+ </para>
+ </listitem>
-<listitem><para> &slony1; n'a aucune fonctionnalité permettant de détecter
- la perte d'un noeud, ni de transformer automatiquement un noeud en maître
- ou en noeud origine.</para>
+ <listitem>
+ <para>
+ &slony1; n'a aucune fonctionnalité permettant de détecter la perte d'un
+ nœud, et ne peut pas transformer automatiquement un nœud en
+ maître ou esclave.
+ </para>
-<para> Il est toutefait possible que vous ayez besoin de ce type de mécanisme;
- cela vous demandera de combiner des outils réseau qui évaluent
- <emphasis>selon vos critères</emphasis> quels noeuds vous considérez comme
-<quote>actifs</quote> et quels noeuds vous considérez comme <quote>morts</quote>,
-ainsi qu'une politique locale pour déterminer ce qu'il faut faire dans telle ou telle circonstance.
-&slony1; ne vous impose aucune politique.</para></listitem>
+ <para>
+ Il est toutefois possible que vous ayez besoin de ce type de
+ mécanisme ; cela vous demandera de combiner des outils réseau qui
+ évaluent <emphasis>selon vos critères</emphasis> quels nœuds vous
+ considérez comme <quote>actifs</quote> et quels nœuds vous
+ considérez comme <quote>morts</quote>, ainsi qu'une politique locale pour
+ déterminer ce qu'il faut faire dans telle ou telle circonstance. &slony1;
+ ne vous impose aucune politique.
+ </para>
+ </listitem>
-<listitem><para>&slony1; n'est pas un système de réplication multi-maîtres;
- ce n'est pas un gestionnaire de connexions, et il ne vous apportera pas
- le café et les croissants le matin.</para></listitem>
-
+ <listitem>
+ <para>
+ &slony1; n'est pas un système de réplication multi-maîtres ; ce
+ n'est pas un gestionnaire de connexions, et il ne vous apportera pas
+ le café et les croissants le matin.
+ </para>
+ </listitem>
</itemizedlist>
-<para>Ceci étant dit, il existe des outils à votre disposition pour
- simplifier certaines de ces opérations, et il existe un projet en cours
- de développement, <productname>Slony-II</productname>, pour fournir
- des mécanismes <quote>multi-maîtres</quote>. Mais cela constitue
- un projet différent et séparé, implémenté de façon très différente
- de &slony1;, et attentes à propos de &slony1; ne doivent pas se baser
- sur l'espoir placé dans de futurs projets.</para></sect2>
+<para>
+ Ceci étant dit, il existe des outils à votre disposition pour simplifier
+ certaines de ces opérations, et il existe un projet en cours de développement,
+ <productname>Slony-II</productname>, pour fournir des mécanismes
+ <quote>multi-maîtres</quote>. Mais cela constitue un projet différent et
+ séparé, implémenté de façon très différente de &slony1;, et les attentes à
+ propos de &slony1; ne doivent pas se baser sur des espoirs placés dans de
+ futurs projets.
+</para>
-<sect2><title> Pourquoi &slony1; ne fait pas de bascule automatique en cas de panne («fail over») ?
-</title>
+</sect2>
-<para>Déterminer si un noeud est en <quote>échec</quote> est de la responsabilité
- d'un logiciel de surveillance de réseau, pas de &slony1;. La configuration,
- les mécanismes de bascule et les politiques de reprise sur panne sont
- différent selon les sites. Par exemple, la surveillance avec des NICs redondants
- et les mécanismes de haute-disponibilité intelligents qui garantissent
- un changement d'adresse réseau à la volée sans conflit et une isolation
- du noeud <quote>en échec</quote>, dépendent de la configuration du réseau,
- des choix matériels et de la combinaison entre les logiciels et les appareils
- utilisés. Tout cela appartient clairement au domaine de la gestion de réseau,
- pas à celui de &slony1;.</para>
+<sect2>
+<title>Pourquoi &slony1; ne fait pas de bascule automatique en cas de panne
+(« fail over ») ?</title>
-<para> De plus, choisir comment se comporter selon
-<quote>l'état</quote> du cluster concerne la politique commerciale locale,
-en particulier si on considère qu'une <link
-linkend="stmtfailover"><command>bascule en cas de panne</command></link> ( « fail over » ) nécessite
-d'isoler le noeud en échec. Si &slony1; imposait une politique de bascule en cas de panne
-aux utilisateurs, cela entrerait parfois en conflit avec des
-intérêts commerciaux et &slony1; serait parfois une solution inadaptée.</para>
+<para>
+ Déterminer si un nœud est en <quote>échec</quote> est de la
+ responsabilité d'un logiciel de surveillance de réseau, pas de &slony1;.
+ La configuration, les mécanismes de bascule et les politiques de reprise sur
+ panne sont différents selon les sites. Par exemple, la surveillance avec des
+ NIC redondants et les mécanismes de haute-disponibilité intelligents qui
+ garantissent un changement d'adresse réseau à la volée sans conflit et une
+ isolation du nœud <quote>en échec</quote>, dépendent de la configuration
+ du réseau, des choix matériels et de la combinaison entre les logiciels et les
+ appareils utilisés. Tout cela appartient clairement au domaine de la gestion
+ de réseau, pas à celui de &slony1;.
+</para>
-<para>En conséquence, laissons &slony1; faire ce qu'il fait de mieux : fournir un service de
- réplication de bases de données.</para></sect2>
+<para>
+ De plus, choisir comment se comporter selon l'<quote>état</quote> du cluster
+ concerne la politique commerciale locale, en particulier si on considère
+ qu'une <link linkend="stmtfailover"><command>bascule en cas de
+ panne</command></link> (« fail over ») nécessite d'isoler le
+ nœud en échec. Si &slony1; imposait une politique de bascule en cas de
+ panne aux utilisateurs, cela entrerait parfois en conflit avec des intérêts
+ commerciaux et &slony1; serait parfois une solution inadaptée.
+</para>
-<sect2><title> Limitations actuelles</title>
+<para>
+ En conséquence, laissons &slony1; faire ce qu'il fait de mieux :
+ fournir un service de réplication de bases de données.
+</para>
+</sect2>
+
+<sect2>
+<title>Limitations actuelles</title>
+
<indexterm><primary>limitations de &slony1;</primary></indexterm>
-<para>&slony1; ne propage pas les changements du schéma de données,
- et ne réplique non plus les objets volumineux ( «large objects» )
- Il y a une raison unique et commune à ces limitations :
- &slony1; collecte les mises à jours en utilisant des triggers, et
- ni les changements de schéma, ni les opérations sur les objets volumineux,
- ni les requêtes <command>TRUNCATE</command> ne sont capables de
- déclencher des triggers pour informer &slony1; lorsque ce genre
- de modification a lieu. Ainsi les seuls objets que &slony1; peut répliquer
- sont les tables et les séquences. </para>
+<para>
+ &slony1; ne propage pas les changements du schéma de données et ne réplique
+ non plus les objets volumineux (les « large objects »). Il y a une
+ raison unique et commune à ces limitations : &slony1; collecte les mises
+ à jours en utilisant des triggers, et ni les changements de schéma ni les
+ opérations sur les « large objects », ni les requêtes
+ <command>TRUNCATE</command> ne sont capables de déclencher des triggers pour
+ informer &slony1; lorsque ce genre de modifications a lieu. Ainsi les seuls
+ objets que &slony1; peut répliquer sont les tables et les séquences.
+</para>
-<para> Notons que <emphasis>l'utilisation</emphasis> de triggers implique
- quelques <emphasis>retoucher</emphasis> supplémentaires sur ces triggers.
-Sur le noeud <quote>origine</quote> pour chaque table répliquée, on ajoute un trigger
-supplémentaire qui lance la procédure stockée <xref
-linkend="function.logtrigger"/>.
-Sur chaque noeud abonné, les tables sont complétées avec un trigger qui lance
-la fonction <xref
-linkend="function.denyaccess"/>; cette fonction empêche toute mise à jour
-sur les tables répliquées à l'exception de celles effectuées par
-le processus <xref linkend="slon"/>.
-De plus, toutes les <emphasis>autres</emphasis> triggers et règles
-sur les tables répliquées sont <emphasis>supprimés</emphasis> sur
-les noeuds abonnés; Ceci est réalisé en faisant pointant ces tables,
-dans le catalogue système, vers les index des clefs primaires
-plutôt que sur la table elle-même.
-Cela s'apparente à une <quote>corruption</quote> du dictionnaire de données,
-et cela explique pourquoi on ne peut pas utiliser directement
- <application>pg_dump</application> pour exporter le schéma sur les
- noeuds abonnés. </para>
+<para>
+ Notons que l'<emphasis>utilisation</emphasis> de triggers implique quelques
+ <emphasis>retouches</emphasis> supplémentaires sur ces triggers. Sur le
+ nœud <quote>origine</quote> pour chaque table répliquée, on ajoute un
+ trigger supplémentaire qui lance la procédure stockée <xref
+ linkend="function.logtrigger"/>. Sur chaque nœud abonné, les tables
+ sont complétées avec un trigger qui lance la fonction <xref
+ linkend="function.denyaccess"/> ; cette fonction empêche toute mise à
+ jour sur les tables répliquées à l'exception de celles effectuées par le
+ processus <xref linkend="slon"/>. De plus, tous les
+ <emphasis>autres</emphasis> triggers et règles sur les tables répliquées sont
+ <emphasis>supprimés</emphasis> sur les nœuds abonnés ; ceci est
+ réalisé en faisant pointer ces tables, dans le catalogue système, vers les
+ index des clefs primaires plutôt que sur la table elle-même. Cela s'apparente
+ à une <quote>corruption</quote> du dictionnaire de données, et cela explique
+ pourquoi on ne peut pas utiliser directement <application>pg_dump</application>
+ pour exporter le schéma sur les nœuds abonnés.
+</para>
-<para>Il est possible de propager d'autres types de modifications des bases
- avec &slony1;, notamment les ordres DDL, si vous les effectuer via la fonction
+<para>
+ Il est possible de propager d'autres types de modifications des bases avec
+ &slony1;, notamment les ordres DDL si vous les effectuez via la fonction
de <application>slonik</application> nommée <xref
-linkend="stmtddlscript"/>. Ceci ne peut pas se faire
-<quote>automatiquement</quote>; en tant qu'administrateur de base de données,
-vous devez superviser les scripts SQL DDL et les soumettre via <xref
-linkend="stmtddlscript"/> car il existe un certain nombre de
-pièges à éviter concernant les <link
-linkend="ddlchanges">.</link> </para>
+ linkend="stmtddlscript"/>. Ceci ne peut pas se faire
+ <quote>automatiquement</quote> ; en tant qu'administrateur de base de
+ données, vous devez superviser les scripts SQL DDL et les soumettre via
+ <xref linkend="stmtddlscript"/> car il existe un certain nombre de pièges
+ à éviter concernant les <link linkend="ddlchanges"></link>.
+</para>
-<para>Si vous ne pouvez pas superviser ces modifications, vous devrez peut-être
+<para>
+ Si vous ne pouvez pas superviser ces modifications, vous devrez peut-être
envisager l'utilisation du mécanisme <acronym>PITR</acronym> (Point In
-Time Recovery) de &postgres; (version 8.x), avec lequel les journaux
-<acronym>WAL</acronym> sont répliqués sur des noeuds distants.
-Malheureusement cette solution à deux limitations majeures :
+ Time Recovery) de &postgres; (version 8.x), avec lequel les journaux de
+ transactions sont répliqués sur des nœuds distants. Malheureusement,
+ cette solution a deux limitations majeures :
-<itemizedlist>
-
-<listitem><para> Le mécanisme PITR replique <emphasis>tous</emphasis> les changements de
-<emphasis>toutes</emphasis> les bases de données; vous ne pouvez pas
-exclure les données qui ne sont pas intéressantes;</para></listitem>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Le mécanisme PITR réplique <emphasis>tous</emphasis> les changements
+ de <emphasis>toutes</emphasis> les bases de données ; vous ne
+ pouvez pas exclure les données qui ne sont pas intéressantes ;
+ </para>
+ </listitem>
-<listitem><para> Un réplicat PITR reste endormi jusqu'à ce que les journaux
- soient appliqués et que la base soit relancée. Vous ne pouvez pas
- utiliser la base et appliquer les mises à jour simultanément.
- Cela revient à avoir un <quote>serveur de secours</quote> que
- vous ne pouvez utiliser sans stopper la réplication.</para></listitem>
+ <listitem>
+ <para>
+ Un réplicat PITR reste endormi jusqu'à ce que les journaux soient
+ appliqués et que la base soit relancée. Vous ne pouvez pas utiliser la
+ base et appliquer les mises à jour simultanément. Cela revient à avoir
+ un <quote>serveur de secours</quote> que vous ne pouvez utiliser sans
+ stopper la réplication.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
-</itemizedlist></para>
</sect2>
-<sect2><title>Modèles de réplication</title>
-
+<sect2>
+<title>Modèles de réplication</title>
<indexterm><primary>modèles de réplication</primary></indexterm>
-<para>%Il beaucoup de modèles de réplication différents; il est
- qu'un système de réplication puisse répondre à toutes les attentes
- de tous les utilisateurs.</para>
+<para>
+ Il existe beaucoup de modèles de réplication différents ; il n'existe
+ pas une seul système de réplication qui puisse répondre à toutes les attentes
+ de tous les utilisateurs.
+</para>
-<para> &slony1; implémente un modèle particulier, la réplication asynchrone,
- en utilisant des triggers pour collecter les mises à jour sur les tables,
- sur une <quote>origine</quote> unique, puis réplique ces mises à jour
- sur de multiple <quote>abonnés</quote>, y compris les abonnés en cascade.</para>
+<para>
+ &slony1; implémente un modèle particulier, la réplication asynchrone, en
+ utilisant des triggers pour collecter les mises à jour sur les tables, sur
+ une <quote>origine</quote> unique, puis réplique ces mises à jour sur de
+ multiples <quote>abonnés</quote>, y compris les abonnés en cascade.
+</para>
-<para> Il existe de de nombreaux autres modèles de réplication
- qui sont <emphasis> différent </emphasis> de celui-ci; il est
- important de souligner que d'autres approches sont possibles.
- &slony1; n'est certainement pas la seule approche, et pour certaines
- applications, ce n'est <emphasis> pas </emphasis> la meilleur approche. </para>
+<para>
+ Il existe de de nombreux autres modèles de réplication qui sont
+ <emphasis>différents</emphasis> de celui-ci ; il est important de
+ souligner que d'autres approches sont possibles. &slony1; n'est certainement
+ pas la seule approche et, pour certaines applications, ce n'est
+ <emphasis>pas</emphasis> la meilleur approche.
+</para>
<itemizedlist>
-<listitem><para> Réplication synchrone entre une origine unique et plusieurs abonnés</para>
+ <listitem>
+ <para>
+ Réplication synchrone entre une origine unique et plusieurs abonnés
+ </para>
-<para> Dans un système synchrone, les mises à jour ne peuvent pas être committées
- sur l'origine tant qu'elles n'ont pas été acceptées par les noeuds abonnés.
- Ceci renforce la sécurité en évitant les risques de répudiation, car les mises
- à jour ne sont pas effectuées sans avoir été confirmées ailleurs. Malheureusement,
- la nécessité d'appliquer simultanément les changements sur de multiple emplacement
- constitue un frein sur les performances. </para>
+ <para>
+ Dans un système synchrone, les mises à jour ne peuvent pas être validées
+ sur l'origine tant qu'elles n'ont pas été acceptées par les nœuds
+ abonnés. Ceci renforce la sécurité en évitant les risques de répudiation
+ car les mises à jour ne sont pas effectuées sans avoir été confirmées
+ ailleurs. Malheureusement, la nécessité d'appliquer simultanément les
+ changements sur de multiples emplacements constitue un frein sur les
+ performances.
+ </para>
-<para> Cette approche est similaire au modèle basé sur le commit en deux phases ( NdT : « two phase commit » )
- implémenté dans le protocole de gestion de transaction XA.</para>
-</listitem>
+ <para>
+ Cette approche est similaire au modèle basé sur la validation en deux
+ phases (NdT : « two phase commit ») implémenté dans le
+ protocole de gestion de transaction XA.
+ </para>
+ </listitem>
-<listitem><para> Réplication synchrone entre plusieurs origines et plusieurs abonnés </para>
+ <listitem>
+ <para>
+ Réplication synchrone entre plusieurs origines et plusieurs abonnés
+ </para>
-<para> Ceci est le modèle implémenté dans l'hypothétique système
-<productname>Slony-II</productname>. Les systèmes de réplication synchrones
-<quote>souffrent</quote> de problèmes de performances, car les mises à jour doivent
-être acceptées par tous les noeuds avant d'être appliquées.</para>
+ <para>
+ Ceci est le modèle implémenté dans l'hypothétique système
+ <productname>Slony-II</productname>. Les systèmes de réplication synchrones
+ <quote>souffrent</quote> de problèmes de performances car les mises à jour
+ doivent être acceptées par tous les nœuds avant d'être appliquées.
+ </para>
-<para> En pratique, il est inutile de faire fonctionner un système de réplication
- synchrone sur un réseau longue distance (WAN).</para>
-</listitem>
+ <para>
+ En pratique, il est inutile de faire fonctionner un système de réplication
+ synchrone sur un réseau longue distance (WAN).
+ </para>
+ </listitem>
-<listitem><para> Réplication asynchrone multi-maîtres avec résolution/prévention des conflits</para>
+ <listitem>
+ <para>
+ Réplication asynchrone multi-maîtres avec résolution/prévention des conflits
+ </para>
-<para> Le système de réplication le plus répandu utilisant ce modèle est probablement
- le système <productname>PalmOS HotSync</productname>.
-<trademark>Lotus Notes</trademark> fournit également un système de réplication
-qui fonctionne de la même manière.</para>
+ <para>
+ Le système de réplication le plus répandu utilisant ce modèle est
+ probablement le système <productname>PalmOS HotSync</productname>.
+ <trademark>Lotus Notes</trademark> fournit également un système de
+ réplication qui fonctionne de la même manière.
+ </para>
-<para> Le <quote>problème</quote> caractéristique avec ce
-style de réplication est que des conflits peuvent apparaître
-lorsque des utilisateurs mettent à jour le même enregistrement
-de différente manière sur différents noeuds.</para>
+ <para>
+ Le <quote>problème</quote> caractéristique avec ce style de réplication
+ est que des conflits peuvent apparaître lorsque des utilisateurs mettent
+ à jour le même enregistrement de différentes manières sur différents
+ nœuds.
+ </para>
-<para> Dans le cas de <productname>HotSync</productname>, si un conflit
- est provoqué par la mise à jour simultanée d'un même enregistrement,
- la <quote>résolution</quote> se résume à créer un deuxième enregistrement
- pour témoigner des deux mises à jours, puis laisser l'utilisateur résoudre
- le conflit à la main. </para>
+ <para>
+ Dans le cas de <productname>HotSync</productname>, si un conflit est
+ provoqué par la mise à jour simultanée d'un même enregistrement, la
+ <quote>résolution</quote> se résume à créer un deuxième enregistrement
+ pour témoigner des deux mises à jours, puis laisser l'utilisateur
+ résoudre le conflit à la main.
+ </para>
-<para> Certains systèmes de réplication multi-maîtres asynchrones essaient
- de résoudre les conflits en trouvant de moyens pour appliquer partiellement
- les mises à jour. Par exemple, dans le cas de la mise à jour d'un adresse,
- si un autre utilisateur tente de mettre à jour le nom de la rue, alors le
- système de résolution des conflits essaie d'appliquer les mises à jour
- dans un ordre non-conflictuel. On peut considérer cette méthode comme
- une forme de <quote>partitionnement de table</quote> où l'on considère la
- base de données comme une table constituée de plusieurs <quote>sous-tables</quote>. </para>
+ <para>
+ Certains systèmes de réplication multi-maîtres asynchrones essaient de
+ résoudre les conflits en trouvant des moyens pour appliquer partiellement
+ les mises à jour. Par exemple, dans le cas de la mise à jour d'un adresse,
+ si un autre utilisateur tente de mettre à jour le nom de la rue, alors le
+ système de résolution des conflits essaie d'appliquer les mises à jour
+ dans un ordre non conflictuel. On peut considérer cette méthode comme
+ une forme de <quote>partitionnement de table</quote> où l'on considère la
+ base de données comme une table constituée de plusieurs <quote>sous
+ tables</quote>.
+ </para>
-<para> Les systèmes de résolution de conflit nécessaire presque toujours
- une bonne connaissance du domaine de l'application, ce qui implique
- qu'ils ne peuvent résoudre des conflits automatiquement uniquement si
- vous leur indiquez une politique de résolution. S'ils rencontrent
- un conflit et qu'il n'existe pas de politique définie, la réplication
- s'arrête jusqu'à ce que quelqu'un résolve le conflit à la main.</para>
-</listitem>
-
+ <para>
+ Les systèmes de résolution de conflit nécessite presque toujours une
+ bonne connaissance du domaine de l'application, ce qui implique qu'ils
+ ne peuvent résoudre des conflits automatiquement uniquement si vous leur
+ indiquez une politique de résolution. S'ils rencontrent un conflit et
+ qu'il n'existe pas de politique définie, la réplication s'arrête jusqu'à
+ ce que quelqu'un résolve le conflit à la main.
+ </para>
+ </listitem>
</itemizedlist>
</sect2>
+
</sect1>
-<sect1 id="slonylistenercosts"><title> Coûts de communications avec &slony1;</title>
+<sect1 id="slonylistenercosts">
+<title> Coûts de communications avec &slony1;</title>
-<para>Le coût de communications augmente de façon quadratique dans plusieurs
-directions lorsque le nombre de noeuds de réplication du cluster
-grandit. Notons les relations suivantes :
+<para>
+ Le coût de communications augmente de façon quadratique dans plusieurs
+ directions lorsque le nombre de nœuds de réplication du cluster
+ grandit. Notons les relations suivantes :
-<itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Il est nécessaire que les entrées de la table <xref
+ linkend="table.sl-listen"/> autorisent toutes les connexions entre tous
+ les nœuds. Dans la plupart des cas, cela n'est pas très
+ volumineux mais cela signifie tout de même qu'il faut définir n(n-1)
+ voies de communications.
+ </para>
+ </listitem>
-<listitem><para> Il est nécessaire que les entrées de la table <xref
-linkend="table.sl-listen"/> autorise toutes les connexions entre tous les noeuds.
-Dans le pluspart des cas, cela n'est pas très volumineux, mais cela signifie tout
-de même qu'il faut définir n(n-1) voies de communications.
-</para></listitem>
+ <listitem>
+ <para>
+ Chaque événement SYNC appliqué doit être annoncé à tous les nœuds
+ participants à la réplication de l'ensemble de données, afin que chaque
+ nœud sache qu'il est possible de purger les données des tables
+ <xref linkend="table.sl-log-1"/> et <xref linkend="table.sl-log-2"/>,
+ car n'importe quel nœud <quote>fournisseur</quote> peut
+ potentiellement devenir un <quote>maître</quote> à tout moment. On peut
+ s'attendre à que les messages SYNC ne soient propagés que sur n/2
+ nœuds pour atteindre leur destination ; ce qui implique que
+ chaque SYNC est transmis n(n/2) fois. À nouveau, cela montre que la
+ croissance des coûts de communication est quadratique selon le nombre
+ de nœuds dans le cluster.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
-<listitem><para> Chaque événement SYNC appliqué doit être annoncé à
- tous les noeuds participants à la réplication de l'ensemble de
- données, afin que chaque noeud sache qu'il est possible de
- purger les données des tables <xref linkend="table.sl-log-1"/> et <xref
-linkend="table.sl-log-2"/>, car n'importe quel noeud <quote>fournisseur</quote>
- peut potentiellement devenir un <quote>maître</quote> à tout moment.
- On peut s'attendre à que les messages SYNC ne soient propagés que sur
- n/2 noeuds pour atteindre leur destination; ce qui implique que
- chaque SYNC est transmis n(n/2) fois. A nouveau, cela montre
- que la croissance des coûts de communication est quadratique selon
- le nombre de noeuds dans le cluster.</para></listitem>
+<para>
+ Tout ceci prouve qu'il n'est pas judicieux de bâtir un grand réseau de
+ communication pour supporter un système de réplication contenant beaucoup
+ de nœuds. Jusqu'à une demi-douzaine de nœuds, cela semble
+ raisonnable ; à chaque fois que le nombre de nœuds double, les
+ temps de communications quadruplent.
+</para>
-</itemizedlist></para>
-
-<para>Tout ceci prouve qu'il n'est pas judicieux de bâtir un grand réseau de communication
- pour supporter un système de réplication contenant beaucoup de noeuds.
- Jusqu'à une demi-douzaine de noeuds cela semble raisonnable; à chaque fois que
- le nombre de noeuds double, les temps de communications quadruplent.</para>
</sect1>
Modified: traduc/trunk/slony/prerequisites.xml
===================================================================
--- traduc/trunk/slony/prerequisites.xml 2009-02-02 17:40:15 UTC (rev 1237)
+++ traduc/trunk/slony/prerequisites.xml 2009-02-10 22:41:58 UTC (rev 1238)
@@ -1,550 +1,348 @@
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
<sect1 id="requirements">
- <title>Pré requis système</title>
+<title>Prérequis système</title>
- <para>
- N'importe quelle plate forme capable de faire tourner
- &postgres;
- devrait être capable, en principe, de faire tourner
- &slony1;.
- </para>
+<para>
+ N'importe quelle plate-forme capable de faire tourner &postgres; devrait
+ être capable, en principe, de faire fonctionner &slony1;.
+</para>
- <indexterm>
- <primary>
- plates formes sur lesquelles
- &slony1;
- tourne
- </primary>
- </indexterm>
+<indexterm><primary>plates-formes sur lesquelles &slony1; fonctionne</primary></indexterm>
- <para>
- Les plates formes ayant été testées spécifiquement à ce jour pour cette release
- sont FreeBSD-4X-i368, FreeBSD-5X-i386,FreeBSD-5X-alpha, OS-X-10.3,
- Linux-2.4X-i386 Linux-2.6X-i386, Linux-2.6X-amd64,
- <trademark>Solaris</trademark>
- -2.8-SPARC,
- <trademark>Solaris</trademark>
- -2.9-SPARC, AIX 5.1, OpenBSD-3.5-sparc64 et
- &windows;
- 2000, XP et 2003 (32 bit).
- </para>
+<para>
+ Les plates-formes ayant été testées spécifiquement à ce jour pour cette
+ version sont FreeBSD-4X-i368, FreeBSD-5X-i386,FreeBSD-5X-alpha, OS-X-10.3,
+ Linux-2.4X-i386 Linux-2.6X-i386, Linux-2.6X-amd64,
+ <trademark>Solaris</trademark>-2.8-SPARC,
+ <trademark>Solaris</trademark>-2.9-SPARC, AIX 5.1, OpenBSD-3.5-sparc64 et
+ &windows; 2000, XP et 2003 (32 bit).
+</para>
- <sect2>
- <title>
- &slony1;
- Dépendances logicielles
- </title>
+<sect2>
+<title>Dépendances logicielles</title>
+<indexterm><primary>dépendances logicielles</primary></indexterm>
- <indexterm>
- <primary>Dépendances logicielles</primary>
- </indexterm>
+<para>
+ À ce jour, &slony1; nécessite d'être compilé depuis ses sources sur votre
+ site <emphasis>de la même façon que &postgres;</emphasis>.
+</para>
- <para>
- A ce jour,
- &slony1;
- <emphasis>
- de la même façon que
- &postgres;
- </emphasis>
- nécessite d'être compilé depuis ses sources sur votre site.
- </para>
+<para>
+ Afin de compiler &slony1;, vous avez besoin des outils suivants :
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ GNU make. Les autres programmes make ne fonctionnent pas. GNU make est
+ souvent installé sous le nom de <command>gmake</command>, qui sera
+ référencé sous ce nom tout au long de ce document. (Sur les systèmes
+ linux, GNU make est le make par defaut, et se nomme
+ <command>make</command>) Pour tester si votre make est GNU make, entrez
+ <command>make version</command>. La version 3.76 ou supérieure
+ convient ; les versions antérieures ne conviennent pas.
+ </para>
+ </listitem>
- <para>
- Afin de compiler
- &slony1;, vous avez besoin des outils suivants :
+ <listitem>
+ <para>
+ Vous avez besoin du compilateur C ISO/ANSI. Les versions récentes de
+ <application>GCC</application> fonctionnent.
+ </para>
+ </listitem>
- <itemizedlist>
- <listitem>
- <para>
- GNU make. Les autres programmes make ne fonctionnent pas. GNU
- make est souvent installé sous le nom de
- <command>gmake</command>
- ; qui sera référencé sous ce nom tout au long de ce document. (Sur les systèmes linux, GNU
- make est le make par defaut, et se nomme
- <command>make</command>
- ) Pour tester si votre make est GNU make entrez
- <command>make version</command>
- . La version 3.76 ou supérieure convient; les versions antérieures ne conviennent pas.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Vous avez également besoin d'une version <emphasis>source</emphasis>
+ récente de &postgres;. &slony1; dépend du support des schémas, ce qui
+ nécessite au minimum une version 7.3.3 de &postgres; pour pouvoir
+ compiler et utiliser &slony1;.
+ </para>
- <listitem>
- <para>
- Vous avez besoin du compilateur C ISO/ANSI. Les versions
- récentes de
- <application>GCC</application>
- fonctionnent.
- </para>
- </listitem>
+ <para>
+ Les versions antérieures de &postgres; <emphasis>ne sont pas</emphasis>
+ supportées, mais notez qu'un utilisateur a réussi à <quote>forcer</quote>
+ l'utilisation de &slony1; dans le cadre d'une migration d'une version
+ 7.2 vers une version 7.4 ; voir les <link linkend="v72upgrade">notes
+ sur &postgres; 7.2</link>.
+ </para>
- <listitem>
- <para>
- Vous avez également besoin d'une version
- <emphasis>source</emphasis>
- récente de &postgres;.
- &slony1;
- dépend du support namespace, nécessitant une
- version 7.3.3 de
- &postgres;
- ou plus récente pour pouvoir compiler et utiliser
- &slony1;.
- </para>
+ <para>
+ Les versions de &postgres; antérieures à la 7.4.8 peuvent rencontrer
+ une requête sans fin conduisant à un problème de <link
+ linkend="dupkey"><quote>duplicate keys</quote></link> (clés dupliquées),
+ vous devrez alors envisager une mise à jour pour éviter ce type d'erreur.
+ </para>
- <para>
- Les versions antérieures de
- &postgres;
- <emphasis>ne sont pas</emphasis>
- supportées, mais notez qu'un utilisateur a
- <quote>forcé</quote>
- l'utilisation de &slony1;
- dans le cadre d'une migration d'une version 7.2 vers une version 7.4; voir
- <link linkend="v72upgrade">
- &postgres;
- 7.2 notes
- </link>
- .
- </para>
+ <para>
+ Si vous utiliser une version de &postgres; antérieure à la version 8.0,
+ vous devez vous assurer que les fichiers d'en-tête de serveur sont
+ installés. Si vous installez depuis les sources, cela se fait par la
+ commande <command>make install-all-headers</command>. Sinon, vous
+ rencontrerez le problème <link linkend="missingheaders">missing headers
+ for libpqserver</link> (en-têtes manquants pour libpqserver), comme
+ décrit dans la FAQ.
+ </para>
- <para>
- Les versions de
- &postgres;
- antérieures à la 7.4.8 peuvent rencontrer une requête sans fin
- conduisant à un problème de
- <link linkend="dupkey">
- <quote>duplicate keys</quote>
- </link>
- , vous devrez alors envisager une mise à jour pour éviter ce type d'erreur.
- </para>
+ <para>
+ Si vous utilisez les versions 8.1.0 à 8.1.3, un bogue (corrigé en
+ 8.1.4) empêche la fonction <xref linkend="stmtupdatefunctions"/>
+ de s'exécuter correctement. Pour plus de détails, voir
+ <xref linkend="faq" />, <link linkend="pg81funs">&postgres;
+ 8.1.[0-3]</link>.
+ </para>
+ </listitem>
- <para>
- Si vous utiliser une version de
- &postgres;
- antérieure à la version 8.0, vous devez vous assurer que
- les fichiers d'en-tête de serveur sont installés. Si
- vous installez depuis les sources, cela se fait par la
- commande
- <command>make install-all-headers</command>
- . Sinon, vous rencontrerez le problème
- <link linkend="missingheaders">
- missing headers for libpqserver
- </link>
- décrit dans le FAQ.
- </para>
+ <listitem>
+ <para>
+ Les packages GNU peuvent être inclus dans le packaging standard de
+ votre système d'exploitation ou doivent être recherchés sur votre
+ miroir local GNU (voir <ulink url="http://www.gnu.org/order/ftp.html">
+ http://www.gnu.org/order/ftp.html</ulink> pour une liste) ou
+ <ulink url="ftp://ftp.gnu.org/gnu">ftp://ftp.gnu.org/gnu</ulink>).
+ </para>
+ </listitem>
- <para>
- Si vous utilisez les versions 8.1.0 à 8.1.3,
- un bug (corrigé en 8.1.4) empêche la fonction
- <xref linkend="stmtupdatefunctions" />
- de s'exécuter correctement. Pour plus de détails, voir
- <xref linkend="faq" />
- ,
- <link linkend="pg81funs">
-
- &postgres;
- 8.1.[0-3]
- </link>
- .
- </para>
+ <listitem>
+ <para>
+ Si vous devez obtenir les sources &postgres;, vous pouvez les
+ télécharger depuis votre miroir &postgres; favori. Voir <ulink
+ url="http://www.postgresql.org/mirrors-www.html">
+ http://www.postgresql.org/mirrors-www.html</ulink> pour une liste.
+ </para>
+ </listitem>
- </listitem>
+ <listitem>
+ <para>
+ Cette documentation est écrite en SGML avec <ulink
+ url="http://docbook.com/">DocBook</ulink> et peut être traduite dans
+ de nombreux formats incluant le HTML, le RTF et le PDF en utilisant
+ des outils <ulink url="http://docbook.sourceforge.net/">dans le dépôt
+ DocBook</ulink> avec <ulink
+ url="http://openjade.sourceforge.net/">OpenJade</ulink>.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Les packages GNU peuvent être inclus dans le packaging standard
- de votre système d'exploitation, ou doivent être recherchés sur votre
- miroir local GNU (voir
- <ulink
- url="http://www.gnu.org/order/ftp.html">
- http://www.gnu.org/order/ftp.html
- </ulink>
- pour une liste) ou
- <ulink url="ftp://ftp.gnu.org/gnu">
- ftp://ftp.gnu.org/gnu
- </ulink>
- .)
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Sous &windows;, vous aurez aussi besoin de la boîte à outils <ulink
+ url="http://www.postgresql.org/docs/faqs.FAQ_MINGW.html">MinGW/
+ Msys</ulink> pour compiler les versions 8.0 et supérieures de
+ &postgres;. De plus, vous devez installer <ulink
+ url="http://sourceware.org/pthreads-win32/">pthreads-win32 2.x</ulink>.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
- <listitem>
- <para>
- Si vous devez obtenir les sources
- &postgres;
- , vous pouvez les télécharger depuis votre miroir
- &postgres;
- favori. Voir
- <ulink
- url="http://www.postgresql.org/mirrors-www.html">
- http://www.postgresql.org/mirrors-www.html
- </ulink>
- pour une liste.
- </para>
- </listitem>
+<para>
+ Assurez-vous de disposer de suffisamment d'espace libre. Vous aurez besoin
+ d'environ 5 Mo pour la distribution des sources pendant la compilation
+ et l'installation.
+</para>
- <listitem>
- <para>
- Cette documentation est écrite en SGML avec
- <ulink url="http://docbook.com/">DocBook</ulink>
- , et peut être traduite dans de nombreux formats
- incluant le HTML, le RTF, et le PDF en utilisant des outils
- <ulink url="http://docbook.sourceforge.net/">
- dans le repository DocBook
- </ulink>
- avec
- <ulink url="http://openjade.sourceforge.net/">
- OpenJade.
- </ulink>
- </para>
- </listitem>
+<note>
+ <para>
+ Dans la version 1.1 de &slony1;, il est possible de compiler &slony1;
+ séparemment de &postgres;, rendant libres les distributions
+ <productname>Linux</productname> et
+ <productname>FreeBSD</productname> d'inclure des packages binaires
+ précompilés pour &slony1;. Si de tels packages ne sont pas disponibles,
+ vous devez vous préparer à compiler &slony1; par vous-même.
+ </para>
+</note>
- <listitem>
- <para>
- Sous
- &windows;
- aurez aussi besoin de la boîte à outils
- <ulink
- url="http://www.postgresql.org/docs/faqs.FAQ_MINGW.html">
- MinGW/Msys
- </ulink>
- pour compiler les versions 8.0 et supérieures de
- &postgres;
- . De plus, vous devez installer
- <ulink
- url="http://sourceware.org/pthreads-win32/">
- pthreads-win32 2.x
- </ulink>
- .
- </para>
- </listitem>
+</sect2>
- </itemizedlist>
- </para>
+<sect2>
+<title>Obtenir les sources de &slony1;</title>
+<indexterm><primary>téléchargement des sources de &slony1;</primary></indexterm>
- <para>
- Assurez-vous de disposer de suffisamment d'espace libre. Vous
- aurez besoin d'environ 5MB pour la distribution des sources pendant la compilation
- et l'installation.
- </para>
+<para>
+ Vous pouvez obtenir les sources de &slony1; à partir de l'url <ulink
+ url="http://main.slony.info/downloads/">http://main.slony.info/downloads/</ulink>.
+</para>
- <note>
- <para>
- Dans la version 1.1 de
- &slony1;
- , il est possible de compiler
- &slony1;
- séparemment de
- &postgres;, rendant libres les distributions
- <productname>Linux</productname>
- et
- <productname>FreeBSD</productname>
- d'inclure des packages binaires précompilés pour
- &slony1;. Si de tels packages ne sont pas disponibles, vous devez
- vous préparer à compiler
- &slony1;
- par vous-même.
- </para>
- </note>
- </sect2>
+</sect2>
- <sect2>
- <title>
- Obtenir les sources de
- &slony1;
- </title>
+<sect2 id="encoding">
+<title>Encodage d'une base de données</title>
+<indexterm><primary>encodage d'une base de données</primary></indexterm>
- <indexterm>
- <primary>
- téléchargement des sources de
- &slony1;
- </primary>
- </indexterm>
+<para>
+ Les bases de données &postgres; peuvent être créés avec plusieurs types
+ d'encodage, défini par la commande &slony1; <command>createdb
+ --encoding=$ENCODING databasename</command>. Cela suppose que les bases de
+ données utilisent des encodages <emphasis>identiques.</emphasis>
+</para>
- <para>
- Vous pouvez obtenir les sources de
- &slony1;
- à partir de l'url
- <ulink url="http://main.slony.info/downloads/">
- http://main.slony.info/downloads/
- </ulink>
- </para>
+<para>
+ Des encodages <quote>très proches</quote> peuvent ne provoquer aucun problème.
+ Par exemple, si le système d'origine utilise <envar>LATIN1</envar>, un
+ abonné <envar>SQL_ASCII</envar> et un autre abonné <envar>UNICODE</envar>,
+ et que votre application ne dépasse pas les conditions limites de frontière
+ entre ces différents encodages, vous pouvez ne jamais rencontrer de problème.
+</para>
- </sect2>
+<para>
+ Dans la version 8.1 de &postgres;, des modifications ont été apportées à
+ l'encodage <envar>UNICODE</envar> car les versions précédentes acceptaient
+ des encodages invalides. Cela pouvait conduire à des <link
+ linkend="faqunicode">problèmes de replication</link>.
+</para>
- <sect2 id="encoding">
- <title>Encodage base de données</title>
+<para>
+ Notez que si l'encodage client (configuré soit dans
+ <filename>postgresql.conf</filename>, soit par le paramètre
+ <envar>client_encoding</envar>, soit par la commande
+ <application>psql</application> <command>\encoding</command>, soit sous
+ <application>psql</application> par la variable interne
+ <envar>ENCODING</envar>) diffère de l'encodage serveur, cette différence
+ peut conduire &slony1; à être incapable de répliquer les caractères
+ supportés par l'encodage client et non pas par celui du serveur.
+</para>
- <indexterm>
- <primary>Encodage base de données</primary>
- </indexterm>
+</sect2>
- <para>
-
- Les bases de données &postgres; peuvent être créés avec plusieurs types d'encodage,
- défini par la commande
- <command>
- createdb --encoding=$ENCODING databasename
- </command>
- .
- &slony1;
- suppose que les bases de données utilisent des encodages
- <emphasis>identiques.</emphasis>
- </para>
+<sect2 id="times">
+<title>Synchronisation horloge</title>
+<indexterm><primary>synchronisation horloge</primary></indexterm>
- <para>
- Des encodages
- <quote>très proches</quote>
- peuvent ne provoquer aucun problème.
- Par exemple, si le système d'origine utilise
- <envar>LATIN1</envar>
- et un abonné
- <envar>SQL_ASCII</envar>
- et un autre abonné
- <envar>UNICODE</envar>
- , et que votre application ne dépasse pas les conditions limites de frontière
- entre ces différents encodages, vous pouvez ne jamais rencontrer
- de problème.
- </para>
+<para>
+ Tous les serveurs utilisés dans le cluster de réplication doivent avoir
+ leurs horloges internes synchronisées. Cela garantie que <xref
+ linkend="slon"/> ne génère pas d'erreur indiquant qu'un abonné est en
+ avance par rapport à son fournisseur pendant la réplication.
+ L'analyse des journaux applicatifs sur des serveurs ayant une idée différente
+ du temps est source de confusion et de frustration. Il est recommandé de
+ faire tourner le démon <application>ntpd</application> sur tous les
+ nœuds, où les nœuds abonnés utilisent le nœud
+ <quote>maître</quote> comme serveur de temps.
+</para>
- <para>
- Dans la version 8.1 de
- &postgres;
- , des modifications ont été apportées à l'encodage
- <envar>UNICODE</envar>
- car les versions précédentes acceptaient des encodages invalides.
- Cela pouvait conduire à des
- <link linkend="faqunicode">problèmes de replication.</link>
- </para>
+<para>
+ Il est possible pour &slony1; de fonctionner avec des différences de temps,
+ mais avoir des systèmes <quote>synchonisés</quote> est normalement très
+ important pour les applications distribuées.
+</para>
- <para>
- Notez que si l'encodage client (configuré soit
- dans
- <filename>postgresql.conf</filename>
- , par le paramètre
- <envar>client_encoding</envar>
- , ou soit par la commande
- <application>psql</application>
- <command>\encoding</command>
- , ou sous
- <application>psql</application>
- par la variable interne
- <envar>ENCODING</envar>
- ) diffère de l'encodage serveur, cette différence peut conduire
- &slony1;
- a être incapable de répliquer les caractères supportés par l'encodage
- client et non pas par celui du serveur.
- </para>
+<para>
+ Voir <ulink url="http://www.ntp.org/">www.ntp.org</ulink> pour plus de
+ détails au sujet de NTP (Network Time Protocol).
+</para>
- </sect2>
+<para>
+ Quelques utilisateurs ont reporté des problèmes lors de l'utilisation de
+ certaines zones de temps, non reconnues par &postgres;.
- <sect2 id="times">
- <title>Synchronisation horloge</title>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Sur <productname>AIX</productname>, <command><envar>TZ</envar>=CUT0</command>
+ était non reconnu, conduisant à des échecs d'appels système lors de la
+ recherche d'un horodatage.
+ </para>
- <indexterm>
- <primary>Synchronisation horloge</primary>
- </indexterm>
+ <para>
+ <command>CUT0</command> est une variante pour décrire
+ <command>UTC</command>.
+ </para>
+ </listitem>
- <para>
- Tous les serveurs utilisés dans le cluster de réplication doivent avoir
- leurs horloges internes synchronisées. Cela garantie que
- <xref linkend="slon" />
- ne génère pas d'erreur indiquant qu'un
- abonné est en avance par rapport à son fournisseur pendant
- la réplication. L'interprétation des logs sur des serveurs ayant une idée différente du temps
- est source de confusion et de frustration.
- Il est recommandé de faire tourner le démon
- <application>ntpd</application>
- sur tous les noeuds, où les noeuds abonnés utilisent le noeud
- <quote>maître</quote>
- comme serveur de temps.
- </para>
+ <listitem>
+ <para>
+ Quelques zones de temps ne sont pas encore incluses dans &postgres;.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
- <para>
- Il est possible pour
- &slony1;
- de fonctionner avec des différences de temps,
- mais avoir des systèmes
- <quote>synchonisés</quote>
- est normalement très important pour les applications distribuées.
- </para>
+<para>
+ Dans tous les cas, ce qui semble être communément une <quote>bonne
+ pratique</quote> avec &slony1; (et, pour nous &postgres;) est d'utiliser
+ pour l'utilisateur postmaster et/ou l'utilisateur sous lequel
+ <application>slon</application> tourne
+ <command><envar>TZ</envar>=UTC</command> ou
+ <command><envar>TZ</envar>=GMT</command>. Ces fuseaux horaires sont supportées
+ de manière <emphasis>sûres</emphasis> par n'importe quelle plate-forme, ont
+ le mérite par rapport à des fuseaux horaires <quote>locaux</quote> de ne
+ jamais diverger par rapport aux changements heures été-hiver.
+</para>
- <para>
- Voir
- <ulink url="http://www.ntp.org/">www.ntp.org</ulink>
- pour plus de détail au sujet de NTP (Network Time Protocol).
- </para>
+</sect2>
- <para>
- Quelques utilisateurs ont reporté des problèmes
- lors de l'utilisation de certaines zones de temps, non reconnues par
- &postgres;
- .
- <itemizedlist>
+<sect2>
+<title>Connexions réseau</title>
+<indexterm><primary>connexions réseau</primary></indexterm>
- <listitem>
- <para>
- Sur
- <productname>AIX</productname>
- ,
- <command>
- <envar>TZ</envar>
- =CUT0
- </command>
- était non reconnu, conduisant à des échecs d'appels système lors de la
- recherche de timestamps.
- </para>
+<para>
+ Il est nécessaire que les nœuds devant être répliqués entre eux aient
+ des communications réseau <emphasis>bidirectionnelles</emphasis> entre les
+ instances &postgres;. Ainsi, si le nœud B est en train de répliquer les
+ données du nœud A, il est nécessaire qu'il y ait un chemin de A vers B
+ et de B vers A. Il est recommandé que, dans la mesure du possible, tous les
+ nœuds du cluster &slony1; permettent ce type de communication
+ bidirectionnelle de n'importe quel nœud du cluster vers n'importe quel
+ autre nœud du cluster.
+</para>
- <para>
- <command>CUT0</command>
- est une variante pour décrire
- <command>UTC</command>
- </para>
- </listitem>
+<para>
+ Pour faciliter la configuration, les adresses réseau devraient être idéalement
+ identiques à travers tous les nœuds. <xref linkend="stmtstorepath"/>
+ leur permet d'être différentes, mais le maintien de ces différents chemins
+ pointant sur le même serveur peut devenir problématique.
+</para>
- <listitem>
- <para>
- Quelques zones de temps ne sont pas encore incluses
- dans
- &postgres;.
- </para>
- </listitem>
+<para>
+ Un contournement possible de cela, dans les environnements où les règles de
+ parefeu sont particulièrement difficiles à implémenter, peut être d'établir
+ des <ulink url="http://www.brandonhutchinson.com/ssh_tunnelling.html"
+ id="tunnelling">tunnels SSH</ulink> crés sur chaque hôte permettant un accès
+ distant au travers d'une adresse IP locale telle 127.0.0.1, en utilisant un
+ port différent pour chaque destination.
+</para>
- </itemizedlist>
- </para>
+<para>
+ Notez que <application>slonik</application> et les instances
+ <application>slon</application> ne nécessitent pas de connexions ou de
+ protocoles spéciaux pour communiquer ensemble ; ils nécessitent
+ simplement un accès aux bases de données &postgres;, en s'y connectant comme
+ <quote>super utilisateur</quote> <link linkend="morethansuper">capable de
+ mettre à jour les tables du système</link>.
+</para>
- <para>
- Dans tous les cas, ce qui semble être communément une
- <quote>bonne pratique</quote>
- avec
- &slony1;
- (et, pour nous
- &postgres;) est d'utiliser pour l'utilisateur postmaster et/ou l'utilisateur sous lequel
- <application>slon</application>
- tourne
- <command>
- <envar>TZ</envar>
- =UTC
- </command>
- ou
- <command>
- <envar>TZ</envar>
- =GMT
- </command>
- . Ces zones de temps sont supportées de manière
- <emphasis>sûres</emphasis>
- par n'importe quelle plate-forme, ont le mérite par rapport à des timezones
- <quote>locaux</quote>
- de ne jamais diverger par rapport aux changements heures été-hiver.
- </para>
+<para>
+ Une conséquence d'un tel modèle de communication est que le réseau entier
+ dans lequel un cluster &slony1; opère doit être sécurisé. Si une des bases
+ de données du cluster ne peut être considérée comme sécurisée, cela
+ représente une vulnérabilité pour tout le cluster. De la même manière que
+ dans un système <quote>peer-to-peer</quote>, <emphasis>n'importe quel</emphasis>
+ hôte est capable d'envoyer un évènement de réplication affectant tout le
+ cluster. Ainsi, les règles de sécurité du cluster doivent être celles du
+ nœud le plus <emphasis>faible</emphasis>. Faire tourner &slony1;
+ à une localisation qui ne peut être considérée comme sécurisée compromet la
+ sécurité du cluster dans son ensemble.
+</para>
- </sect2>
+<para>
+ Une nouvelle fonctionnalité de &slony1; version 1.1 est que les mises à jour
+ pour un jeu de réplication particulier peuvent être sérialisées via le schéma
+ &logshiplink;. La donnée enregistrée dans <envar>sl_log_1</envar> et
+ <envar>sl_log_2</envar> est aussi écrite dans des journaux de transactions sur
+ disque. Ces fichiers peuvent ensuite être transmis de n'importe quelle manière
+ via scp, FTP, écrits sur DVD-ROM puis adressés par messagerie ou, pourquoi
+ pas, en les enregistrant sur une <quote>clé USB</quote> permettant
+ l'équivalence d'une <ulink url="http://www.faqs.org/rfcs/rfc1149.html">transmission
+ de diagramme IP on avian carriers - RFC 1149</ulink>. Quelque soit le mécanisme de
+ transmission, cela permet un seul accès de communication tel que les abonnés
+ utilisant le log shipping ne nécessitent aucun accès aux autres nœuds
+ &slony1;.
+</para>
- <sect2>
- <title>Connexions réseau</title>
+</sect2>
- <indexterm>
- <primary>Connexions réseau</primary>
- </indexterm>
-
- <para>
- Il est nécessaire que les noeuds devant être répliqués entre eux aient des communications réseau
- <emphasis>bidirectionnelles</emphasis>
- entre les instances
- &postgres;
- . Ainsi, si le noeud B est en train de répliquer les données du noeud A
- , il est nécessaire qu'il y ai un chemin de A vers B et de B vers A.
- Il est recommandé que, dans la mesure du possible, tous les
- noeuds du cluster
- &slony1;
- permettent ce type de communication bidirectionnelle
- de n'importe quel noeud du cluster vers n'importe quel autre noeud du cluster.
- </para>
-
- <para>
- Pour faciliter la configuration, les adresses réseau devraient être
- idéalement identiques à travers tous les noeuds.
- <xref linkend="stmtstorepath" />
- leur permet d'être différentes, mais le maintien de ces différents paths
- pointant sur le même serveur peut devenir problématique.
- </para>
-
- <para>
- Un contournement possible de cela, dans les environnements où
- les règles de firewall sont particulièrement difficiles à implémenter, peut
- être d'établir des tunnels SSH
- <ulink
- url="http://www.brandonhutchinson.com/ssh_tunnelling.html"
- id="tunnelling">
- SSH Tunnels
- </ulink>
- crés sur chaque host permettant un accès distant
- au travers d'une adresse IP locale telle 127.0.0.1, en utilisant un
- port différent pour chaque destination.
- </para>
-
- <para>
- Notez que
- <application>slonik</application>
- et les instances
- <application>slon</application>
- ne nécessitent pas de connexions ou de protocoles spéciaux pour
- communiquer ensemble; ils nécessitent simplement un accès aux bases de données
- &postgres;
- , en s'y connectant comme
- <quote>super utilisateur</quote>
- <link linkend="morethansuper">
- capable de mettre à jour les tables du système.
- </link>
- </para>
-
- <para>
- Une conséquence d'un tel modèle de communication est que
- le réseau entier dans lequel un cluster
- &slony1;
- opère doit être sécurisé.
- Si une des bases de données du cluster ne peut être considérée
- comme sécurisée, cela représente une vulnérabilité pour tout le cluster.
- De la même manière que dans un système
- <quote>peer-to-peer</quote>
- ,
- <emphasis>n'importe quel</emphasis>
- host est capable d'envoyer un évènement de réplication
- affectant tout le cluster. Ainsi, les règles de sécurité du cluster
- doivent être celles du noeud le plus
- <emphasis>faible</emphasis>
- . Faire tourner
- &slony1;
- à une localisation qui ne peut être considérée comme sécurisée
- compromet la sécurité du cluster dans son ensemble.
- </para>
-
- <para>
- Une nouvelle fonctionnalité de
- &slony1;
- version 1.1 est que les mises à jour pour un jeu de réplication particulier
- peuvent être sérialisées via le schéma
- &logshiplink;. La donnée enregistrée dans
- <envar>sl_log_1</envar>
- et
- <envar>sl_log_2</envar>
- est aussi écrite dans des fichiers log sur disque. Ces fichiers peuvent
- ensuite être transmis de n'importe quelle manière
- via scp, FTP, écrits sur DVD-ROMs puis adressés par messagerie, ou, pourquoi pas, en les enregistrant sur
- <quote>une clé USB</quote>
- permettant l'équivalence d'une
- <ulink url="http://www.faqs.org/rfcs/rfc1149.html">
- transmission de diagramme IP on avian carriers - RFC
- 1149.
- </ulink>
- Quelquesoit le mécanisme de transmission, cela permet un seul accès de communication
- tel que les abonnés utilisant le log shipping ne nécessitent aucun accès
- aux autres noeuds
- &slony1;
- .
- </para>
-
- </sect2>
</sect1>
More information about the Trad
mailing list