[Trad] [svn:pgfr] r1124 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Sam 23 Aou 10:20:41 CEST 2008
Author: daamien
Date: 2008-08-23 10:20:41 +0200 (Sat, 23 Aug 2008)
New Revision: 1124
Modified:
traduc/trunk/slony/adminscripts.xml
Log:
slony : adminscripts.xml : a relire
Modified: traduc/trunk/slony/adminscripts.xml
===================================================================
--- traduc/trunk/slony/adminscripts.xml 2008-08-21 17:00:55 UTC (rev 1123)
+++ traduc/trunk/slony/adminscripts.xml 2008-08-23 08:20:41 UTC (rev 1124)
@@ -370,48 +370,52 @@
c'est une façon très simple de supprimer des noeuds.</para>
</listitem>
-<listitem><para><envar>LOGHOME </envar> indicates the
-<quote>home</quote> directory for log storage.</para>
+<listitem><para><envar>LOGHOME </envar> indique le répertoire
+<quote>home</quote> pour le stockage des journaux applicatifs.</para>
-<para> This script does not assume the use of the Apache log rotator
-to manage logs; in that &postgres; version 8 does its own log
-rotation, it seems undesirable to retain a dependancy on specific log
-rotation <quote>technology.</quote> </para></listitem>
+<para> Ce script ne nécessite pas l'utilisation de gestionnaire de logs d'Apache,
+sachant que &postgres; version 8 gère lui-même la rotation des logs,
+il semble inopportun de garder une dépendance à une <quote>technologie</quote>
+de rotation spécifique. </para></listitem>
-<listitem><para><envar>CLUSTERS</envar> is a list of &slony1; clusters
-under management. </para></listitem>
+<listitem><para><envar>CLUSTERS</envar> est la liste des slusters &slony1; qui sont gérés.
+</para></listitem>
</itemizedlist>
-<para> In effect, you could run this every five minutes, and it would
-launch any missing &lslon; processes. </para>
+<para> En pratique, vous pouvez lancer ce programme toutes les cinq minutes, et il relancera tous
+les processus &lslon; manquants. </para>
</sect2>
<sect2 id="extractschema"><title> <filename> slony1_extract_schema.sh </filename> </title>
<indexterm><primary>script - slony1_extract_schema.sh</primary></indexterm>
-<para> You may find that you wish to create a new node some time well
-after creating a cluster. The script <filename>
-slony1_extract_schema.sh </filename> will help you with this.</para>
+<para> Si vous souhaiterez créer un nouveau noeud, après la création du cluster, le script <filename>
+slony1_extract_schema.sh </filename> vous aidera dans cette tache.</para>
-<para> A command line might look like the following:</para>
+<para> La commande d'exécution peut ressembler à la ligne suivante :</para>
<para><command> PGPORT=5881 PGHOST=master.int.example.info ./slony1_extract_schema.sh payroll payroll temppayroll </command> </para>
-<para> It performs the following:</para>
+<para> Elle réalise les actions suivantes :</para>
<itemizedlist>
-<listitem><para> It dumps the origin node's schema, including the data in the &slony1; cluster schema. </para>
+<listitem><para> Elle fait un dump du schéma du noeud origine, y compris les informations du schéma
+du cluster &slony1;. </para>
-<para> Note that the extra environment variables <envar>PGPORT</envar>
-and <envar>PGHOST</envar> to indicate additional information about
-where the database resides. </para></listitem>
+<para> Notons que les variables d'environnement <envar>PGPORT</envar>
+et <envar>PGHOST</envar> fournissent des informations additionnelles sur l'emplacement de la
+base de données. </para></listitem>
-<listitem><para> This data is loaded into the freshly created temporary database, <envar>temppayroll</envar> </para> </listitem>
-<listitem><para> The table and sequence OIDs in &slony1; tables are corrected to point to the temporary database's configuration. </para> </listitem>
-<listitem><para> A slonik script is run to perform <xref linkend="stmtuninstallnode"/> on the temporary database. This eliminates all the special &slony1; tables, schema, and removes &slony1; triggers from replicated tables. </para> </listitem>
-<listitem><para> Finally, <application>pg_dump</application> is run against the temporary database, delivering a copy of the cleaned up schema to standard output. </para> </listitem>
+<listitem><para> Ces informations sont chargées dans une table temporaire fraichement créée : <envar>temppayroll</envar> </para> </listitem>
+<listitem><para> Les OIDs de table et de séquence dans les tables &slony1; sont corrigées pour
+pointer vers la configuration de la base temporaire. </para> </listitem>
+<listitem><para> Un script slonik est lancé pour effecter l'action <xref linkend="stmtuninstallnode"/>
+sur la base temporaire. Ceci élimine toutes les tables et le schéma spécifique à &slony1;
+et supprime les triggers &slony1; des tables répliquées. </para> </listitem>
+<listitem><para> Enfin, la commande <application>pg_dump</application> est lancée sur la base
+temporaire, et produit une copie nettoyée du schéma sur la sortie standard. </para> </listitem>
</itemizedlist>
</sect2>
@@ -419,279 +423,293 @@
<indexterm><primary>script - slony-cluster-analysis</primary></indexterm>
-<para> If you are running a lot of replicated databases, where there
-are numerous &slony1; clusters, it can get painful to track and
-document this. The following tools may be of some assistance in this.</para>
+<para> Si vous exploitez beaucoup de bases répliquées, au sein de plusieurs clusters &slony1;,
+il peut devenir pénible de suivre et de documenter votre architecture.
+L'outil suivant peut vous y aider.</para>
-<para> <application>slony-cluster-analysis.sh</application> is a shell
-script intended to provide some over-time analysis of the
-configuration of a &slony1; cluster. You pass in the usual
-<application>libpq</application> environment variables
+<para> <application>slony-cluster-analysis.sh</application> est un script shell
+conçu pour fournir une analyse à long terme de la configuration d'un cluster
+&slony1;. Vous passez les variables d'environnement
+<application>libpq</application> habituelles
(<envar>PGHOST</envar>, <envar>PGPORT</envar>,
-<envar>PGDATABASE</envar>, and such) to connect to a member of a
-&slony1; cluster, and pass the name of the cluster as an argument.</para>
+<envar>PGDATABASE</envar>, et ainsi de suite) pour se connecter à un membre du cluster
+&slony1;, et passer le nom du cluster comme argument.</para>
-<para> The script then does the following:</para>
+<para> Le script effectue alors les actions suivantes :</para>
<itemizedlist>
-<listitem><para> Runs a series of queries against the &slony1; tables to get lists of nodes, paths, sets, and tables. </para> </listitem>
-<listitem><para> This is stowed in a temporary file in <filename>/tmp</filename> </para> </listitem>
-<listitem><para> A comparison is done between the present configuration and the configuration the last time the tool was run. If the configuration differs, an email of the difference (generated using <application>diff</application>) is sent to a configurable email address. </para> </listitem>
-<listitem><para> If the configuration has changed, the old configuration file is renamed to indicate when the script noticed the change. </para></listitem>
-<listitem><para> Ultimately, the current configuration is stowed in <envar>LOGDIR</envar> in a filename like <filename>cluster.last </filename> </para> </listitem>
+<listitem><para> Lancement d'une séries de requêtes sur les tables &slony1; pour obtenir la liste des
+noeuds, des voies de communication, des ensembles de réplication et des tables.
+ </para> </listitem>
+<listitem><para> Ces données sont stockées dans un fichier temporaire situé dans <filename>/tmp</filename> </para> </listitem>
+<listitem><para> Une comparaison est effectuée entre la configuration présente et la configuration
+trouvée lors de la dernière exécution du script. Si la configuration a changé, un courriel contenant
+les différences ( produit avec <application>diff</application>)
+est envoyée à l'adresse spécifiée. </para> </listitem>
+<listitem><para> Si la configuration a changé, l'ancien fichier de configuration est renommé
+pour indiquer quand le script a remarqué le changement. </para></listitem>
+<listitem><para> Finalement, la configuration courante est stockée dans le dossier
+<envar>LOGDIR</envar> dans un fichier nommé <filename>cluster.last </filename> </para> </listitem>
</itemizedlist>
-<para> There is a sample <quote>wrapper</quote> script,
-<filename>slony-cluster-analysis-mass.sh</filename>, which sets things
-up to point to a whole bunch of &slony1; clusters.</para>
+<para> Il existe une exemple de script <quote>wrapper</quote>,
+<filename>slony-cluster-analysis-mass.sh</filename>, qui permet de
+pointer vers un ensemble de clusters &slony1;.</para>
-<para> This should make it easier for a group of DBAs to keep track of
-two things: </para>
+<para> Ceci devrait simplifier la taches des administrateurs ("DBA") sur deux plans : </para>
<itemizedlist>
-<listitem><para> Documenting the current state of system
-configuration. </para></listitem>
+<listitem><para> La documentation de l'état courant du système.
+</para></listitem>
-<listitem><para> Noticing when configuration
-changes. </para></listitem>
+<listitem><para> La surveillance des changements de configuration. </para></listitem>
</itemizedlist>
</sect2>
-<sect2 id="configurereplication"> <title> Generating slonik scripts
-using <filename>configure-replication.sh</filename> </title>
+<sect2 id="configurereplication"> <title> Génération de scripts slonik avec
+<filename>configure-replication.sh</filename> </title>
-<indexterm><primary> generate slonik scripts for a cluster </primary></indexterm>
+<indexterm><primary> générer des scripts slonik pour un cluster </primary></indexterm>
-<para> The <filename>tools</filename> script
-<filename>configure-replication.sh</filename> is intended to automate
-generating slonik scripts to configure replication. This script is
-based on the configuration approach taken by the <xref
+<para> Le script
+<filename>configure-replication.sh</filename>, situé dans le répertoire <filename>outil</filename>,
+est conçu pour automatiser la génération de scripts slonik de configuration de la
+réplication. La configuration de ce script reprend la même approche que le <xref
linkend="testbed"/>.</para>
-<para> This script uses a number (possibly large, if your
-configuration needs to be particularly complex) of environment
-variables to determine the shape of the configuration of a cluster.
-It uses default values extensively, and in many cases, relatively few
-environment values need to be set in order to get a viable
-configuration. </para>
+<para> Ce script utilise beaucoup ( peut-être énormément, si votre configuration
+est particulièrement complexe) de variables d'environnement pour déterminer
+la forme de la configuration du cluster. Il utilise massivement les valeurs par
+défaut, et dans la plupart des cas, peu de valeurs doivent être positionnées
+afin d'obtenir une configuration viable. </para>
-<sect3><title>Global Values</title>
+<sect3><title>Valeurs Globales</title>
-<para> There are some values that will be used universally across a
-cluster: </para>
+<para> Certaines valeurs sont utilisées universellement partout sur le cluster : </para>
<variablelist>
<varlistentry><term><envar> CLUSTER </envar></term>
-<listitem><para> Name of Slony-I cluster</para></listitem></varlistentry>
+<listitem><para> Le nom du cluster Slony-I </para></listitem></varlistentry>
<varlistentry><term><envar> NUMNODES </envar></term>
-<listitem><para> Number of nodes to set up</para></listitem></varlistentry>
+<listitem><para> Le nombre de noeuds à configurer</para></listitem></varlistentry>
<varlistentry><term><envar> PGUSER </envar></term>
-<listitem><para> name of PostgreSQL superuser controlling replication</para></listitem></varlistentry>
+<listitem><para> Le nom du super-utilisateur qui controle la réplication</para></listitem></varlistentry>
<varlistentry><term><envar> PGPORT </envar></term>
-<listitem><para> default port number</para></listitem></varlistentry>
+<listitem><para> Le numéro du port par défault</para></listitem></varlistentry>
<varlistentry><term><envar> PGDATABASE </envar></term>
-<listitem><para> default database name</para></listitem></varlistentry>
+<listitem><para> Le nom de la base de données par défault</para></listitem></varlistentry>
<varlistentry><term><envar> TABLES </envar></term>
-<listitem><para> a list of fully qualified table names (<emphasis>e.g.</emphasis> - complete with
- namespace, such as <command>public.my_table</command>)</para></listitem></varlistentry>
+<listitem><para> une liste de noms complets de tables (<emphasis>par exemple</emphasis> - un nom
+incluant l'espace de noms tel que <command>public.ma_table</command>)</para></listitem></varlistentry>
<varlistentry><term><envar> SEQUENCES </envar></term>
-<listitem><para> a list of fully qualified sequence names (<emphasis>e.g.</emphasis> - complete with
- namespace, such as <command>public.my_sequence</command>)</para></listitem></varlistentry>
+<listitem><para> une liste de noms complets de séquences (<emphasis>par exemple</emphasis> - un nom
+incluant l'espace de noms tel que <command>public.ma_sequence</command>)</para></listitem></varlistentry>
</variablelist>
-<para>Defaults are provided for <emphasis>all</emphasis> of these
-values, so that if you run
-<filename>configure-replication.sh</filename> without setting any
-environment variables, you will get a set of slonik scripts. They may
-not correspond, of course, to any database you actually want to
-use...</para>
+<para>Des valeurs par défaults sont fournies pour <emphasis>chacune</emphasis> de ces valeurs,
+si bien que si vous lancez <filename>configure-replication.sh</filename>
+sans configurer aucune variable d'environnement, vous obtiendrez
+un ensemble de scripts slonik.
+Bien sûr, ils ne correspondront pas aux bases que vous voudrez configurer...</para>
</sect3>
-<sect3><title>Node-Specific Values</title>
+<sect3><title>Valeur spécifique à un noeud</title>
-<para>For each node, there are also four environment variables; for node 1: </para>
+<para>Pour chaque node, il y a également quatre variables d'environnement;
+pour le noeud 1: </para>
<variablelist>
<varlistentry><term><envar> DB1 </envar></term>
-<listitem><para> database to connect to</para></listitem></varlistentry>
+<listitem><para> La base de données à laquelle les scripts
+doivent se connecter</para></listitem></varlistentry>
<varlistentry><term><envar> USER1 </envar></term>
-<listitem><para> superuser to connect as</para></listitem></varlistentry>
+<listitem><para> Le super-utilisateur utilisé pour la connexion</para></listitem></varlistentry>
<varlistentry><term><envar> PORT1 </envar></term>
-<listitem><para> port</para></listitem></varlistentry>
+<listitem><para> Le port</para></listitem></varlistentry>
<varlistentry><term><envar> HOST1 </envar></term>
-<listitem><para> host</para></listitem></varlistentry>
+<listitem><para> L'hôte</para></listitem></varlistentry>
</variablelist>
-<para> It is quite likely that <envar>DB*</envar>,
-<envar>USER*</envar>, and <envar>PORT*</envar> should be drawn from
-the global <envar>PGDATABASE</envar>, <envar>PGUSER</envar>, and
-<envar>PGPORT</envar> values above; having the discipline of that sort
-of uniformity is usually a good thing.</para>
+<para> Il est très probable que <envar>DB*</envar>,
+<envar>USER*</envar>, et <envar>PORT*</envar> correspondent aux
+variables globales <envar>PGDATABASE</envar>, <envar>PGUSER</envar>, et
+<envar>PGPORT</envar> décrites précédemment;
+Conserver cette correspondance est souvent une bonne chose.</para>
-<para> In contrast, <envar>HOST*</envar> values should be set
-explicitly for <envar>HOST1</envar>, <envar>HOST2</envar>, ..., as you
-don't get much benefit from the redundancy replication provides if all
-your databases are on the same server!</para>
+<para> En revanche, Les valeurs <envar>HOST*</envar> doivent être définies
+explicitement pour <envar>HOST1</envar>, <envar>HOST2</envar>, ...,
+car il n'est pas très malin de mettre en place un système de réplication
+si toutes les bases redondantes se trouvent sur le même serveur !</para>
</sect3>
-<sect3><title>Resulting slonik scripts</title>
+<sect3><title>Les scripts slonik générés</title>
-<para> slonik config files are generated in a temp directory under
-<filename>/tmp</filename>. The usage is thus:</para>
+<para> Les scripts de configuration slonik sont générés dans un repertoire
+temporaire à l'intérieur de <filename>/tmp</filename>.
+Leur usage est le suivant :</para>
<itemizedlist>
-<listitem> <para><filename>preamble.slonik</filename> is a
-<quote>preamble</quote> containing connection info used by the other
-scripts.</para>
+<listitem> <para><filename>preamble.slonik</filename> est un fichier
+<quote>preambule</quote> contenant les informations de connexion utilisées
+par les autres scripts.</para>
-<para> Verify the info in this one closely; you may want to keep this
-permanently to use with future maintenance you may want to do on the
-cluster.</para></listitem>
+<para> Vérifier attentivement celui-ci; vous pourrez le réutiliser pour
+les futures opérations de maintenance que vous effectuerez sur le cluster.
+</para></listitem>
<listitem><para> <filename>create_set.slonik</filename></para>
-<para>This is the first script to run; it sets up the requested nodes
-as being &slony1; nodes, adding in some &slony1;-specific config
-tables and such.</para>
+<para>Ce script est le premier qu'il faut lancer; il paramètre les noeuds
+spécifiés en noeud &slony1;, en y ajoutant les tables et les autres objets
+spécifiques de &slony1;.
+</para>
-<para>You can/should start slon processes any time after this step has
-run.</para></listitem>
+<para>Vous pouvez/devez lancer les processus slon juste après cette étape.</para></listitem>
<listitem><para><filename> store_paths.slonik</filename></para>
-<para> This is the second script to run; it indicates how the &lslon;s
-should intercommunicate. It assumes that all &lslon;s can talk to all
-nodes, which may not be a valid assumption in a complexly-firewalled
-environment. If that assumption is untrue, you will need to modify
-the script to fix the paths.</para></listitem>
+<para> Le second script à exécuter; il indique comment
+les &lslon;s doivent communiquer entre eux. Ce script suppose que
+tous les &lslon; peuvent parler à tous les noeuds, ce qui n'est peut-être
+exact dans un environnement peuplé de pare-feux complexes. Si cette supposition
+n'est pas correcte, vous devez modifier ce script pour corriger les voies de
+communications.</para></listitem>
<listitem><para><filename>create_set.slonik</filename></para>
-<para> This sets up the replication set consisting of the whole bunch
-of tables and sequences that make up your application's database
-schema.</para>
+<para> Ce script configure l'ensemble de réplication composé de toutes
+les tables et les séquences présente dans le schéma de la base de données
+de votre application.</para>
-<para> When you run this script, all that happens is that triggers are
-added on the origin node (node #1) that start collecting updates;
-replication won't start until #5...</para>
+<para> Lorsque vous lancez ce script, la seule actions menées est
+l'ajout de triggers sur le noeud origine (noeud #1) qui vont commencer
+à collecter les mises à jours. La réplication ne commencera qu'à
+l'étape #5...</para>
-<para>There are two assumptions in this script that could be
-invalidated by circumstances:</para>
+<para>Il y a deux suppositions dans ce scripts qui peuvent ne pas être
+valides dans certaines circonstances:</para>
<itemizedlist>
- <listitem><para> That all of the tables and sequences have been
- included.</para>
+ <listitem><para> que toutes les tables et les séquences soit répliquées.</para>
- <para> This becomes invalid if new tables get added to your
- schema and don't get added to the <envar>TABLES</envar>
- list.</para> </listitem>
+ <para> Ceci n'est pas valide lorsque de nouvelles tables
+ sont ajoutée dans votre schéma et qu'elles ne sont pas ajoutées
+ dans le liste <envar>TABLES</envar>.</para> </listitem>
- <listitem><para> That all tables have been defined with primary
- keys.</para>
+ <listitem><para> que toutes les tables sont définies avec des clefs primaires.</para>
- <para> Best practice is to always have and use true primary keys.
- If you have tables that require choosing a candidate primary key
- or that require creating a surrogate key using <xref
- linkend="stmttableaddkey"/>, you will have to modify this script
- by hand to accomodate that. </para></listitem>
+ <para> La bonne pratique est de toujours créer et utiliser de vraies clefs
+ primaires.
+ Si vous avez des tables qui nécessite de choisir une clef primaire candidate ou
+qui nécessite la création d'une clef additionnelle avec la commande <xref
+ linkend="stmttableaddkey"/>, vous devez modifier ce script à la main pour l'accomoder.
+ </para></listitem>
+
</itemizedlist>
</listitem>
<listitem><para> <filename> subscribe_set_2.slonik </filename></para>
- <para> And 3, and 4, and 5, if you set the number of nodes
- higher... </para>
+ <para> et 3, 4, 5, si vous configurez d'autres noeuds... </para>
- <para> This is the step that <quote>fires up</quote>
- replication.</para>
+ <para> Ceci est l'étape qui <quote>déclenche</quote>
+ réplication.</para>
- <para> The assumption that the script generator makes is that all
- the subscriber nodes will want to subscribe directly to the origin
- node. If you plan to have <quote>sub-clusters,</quote> perhaps
- where there is something of a <quote>master</quote> location at each
- data centre, you may need to revise that.</para>
+ <para> Ce script fait la supposition que tous les noeuds abonnés voudront
+s'abonner directement au noeud origine. Si vous souhaitez mettre en place
+des <quote>sous-clusters</quote>,avec peut-être un noeud maître dans chaque
+datacenter, vous devez modifier ces scripts.</para>
- <para> The slon processes really ought to be running by the time you
- attempt running this step. To do otherwise would be rather
- foolish.</para> </listitem>
+<para> Les processus slon doivent fonctionner au moment ou vous réaliser cette
+étape. Il est abusrde de lancer ces scripts lorsque ce n'est pas le cas.
+</para> </listitem>
</itemizedlist>
</sect3>
</sect2>
<sect2 id="bsd-ports-profile"> <title> <filename> slon.in-profiles </filename> </title>
-<subtitle> Apache-Style profiles for FreeBSD <filename>ports/databases/slony/*</filename> </subtitle>
+<subtitle> profiles dans le style d'Apache pour FreeBSD <filename>ports/databases/slony/*</filename> </subtitle>
-<indexterm><primary> Apache-style profiles for FreeBSD </primary> <secondary>FreeBSD </secondary> </indexterm>
+<indexterm><primary> prfiles dans le style d'Apache pour FreeBSD </primary> <secondary>FreeBSD </secondary> </indexterm>
-<para> In the <filename>tools</filename> area, <filename>slon.in-profiles</filename> is a
-script that might be used to start up &lslon; instances at the time of
-system startup. It is designed to interact with the FreeBSD Ports
-system.</para>
+<para> Dans le répertoire <filename>tools</filename>, le script <filename>slon.in-profiles</filename> permet de lancer des instances
+&lslon; lors du démarrage du système. Il est conçu pour interagir avec
+systèmes des ports de FreeBSD.</para>
</sect2>
<sect2 id="duplicate-node"> <title> <filename> duplicate-node.sh </filename> </title>
-<indexterm><primary> duplicating nodes </primary> </indexterm>
-<para> In the <filename>tools</filename> area,
-<filename>duplicate-node.sh</filename> is a script that may be used to
-help create a new node that duplicates one of the ones in the
-cluster. </para>
+<indexterm><primary> dupliquer un noeud </primary> </indexterm>
+<para> Dans le répertoire <filename>tools</filename>, le script
+<filename>duplicate-node.sh</filename> aide à créer un nouveau noeud
+en dupliquant un des noeuds du cluster.
+</para>
-<para> The script expects the following parameters: </para>
+<para> Ce script attend les paramètres suivants : </para>
<itemizedlist>
-<listitem><para> Cluster name </para> </listitem>
-<listitem><para> New node number </para> </listitem>
-<listitem><para> Origin node </para> </listitem>
-<listitem><para> Node being duplicated </para> </listitem>
-<listitem><para> New node </para> </listitem>
+<listitem><para> Le nom du cluster</para> </listitem>
+<listitem><para> Le numéro du nouveau noeud </para> </listitem>
+<listitem><para> Le noeud origine </para> </listitem>
+<listitem><para> Le noeud répliqué </para> </listitem>
+<listitem><para> Le nouveau noeud </para> </listitem>
</itemizedlist>
-<para> For each of the nodes specified, the script offers flags to
-specify <function>libpq</function>-style parameters for
+<para> Pour chaque noeud spécifié, le scripts permet de préciser
+les paramètres de type <function>libpq</function> pour
<envar>PGHOST</envar>, <envar>PGPORT</envar>,
-<envar>PGDATABASE</envar>, and <envar>PGUSER</envar>; it is expected
-that <filename>.pgpass</filename> will be used for storage of
-passwords, as is generally considered best practice. Those values may
-inherit from the <function>libpq</function> environment variables, if
-not set, which is useful when using this for testing. When
-<quote>used in anger,</quote> however, it is likely that nearly all of
-the 14 available parameters should be used. </para>
+<envar>PGDATABASE</envar>, et <envar>PGUSER</envar>; Le fichier
+<filename>.pgpass</filename> peut être utilisé pour le stockage
+des mots de passe, ce qui est généralement considéré comme une
+bonne pratique. Lorsqu'elle ne sont pas définie, ces valeurs peuvent
+hériter des variables d'environnement <function>libpq</function>,
+ce qui est pratique quand on réalise des tests. Toutefois
+lorsque que ce script est utilisé <quote>de manière brutale</quote>,
+il est souvent nécessaire de définir les 14 paramètres disponibles.
+</para>
-<para> The script prepares files, normally in
-<filename>/tmp</filename>, and will report the name of the directory
-that it creates that contain SQL and &lslonik; scripts to set up the
-new node. </para>
+<para> Ce script prépare des fichiers, placés dans
+<filename>/tmp</filename>, et annonce le nom du répertoire
+qu'il a créé pour les scripts SQL et &lslonik; de configuration
+du nouveau noeud. </para>
<itemizedlist>
<listitem><para> <filename> schema.sql </filename> </para>
-<para> This is drawn from the origin node, and contains the <quote>pristine</quote> database schema that must be applied first.</para></listitem>
+<para> Ce script est tiré du noeud origine et contient le schéma
+de données <quote>originel</quote> qui doit être appliqué au départ.</para></listitem>
<listitem><para> <filename> slonik.preamble </filename> </para>
-<para> This <quote>preamble</quote> is used by the subsequent set of slonik scripts. </para> </listitem>
+<para> Ce fichier <quote>preamble</quote> est utilisé par l'ensemble des scripts slonik ci-dessous. </para> </listitem>
+
<listitem><para> <filename> step1-storenode.slonik </filename> </para>
-<para> A &lslonik; script to set up the new node. </para> </listitem>
+<para> Un script &lslonik; qui configure le nouveau noeud.<para> </listitem>
<listitem><para> <filename> step2-storepath.slonik </filename> </para>
-<para> A &lslonik; script to set up path communications between the provider node and the new node. </para> </listitem>
+<para> Un script &lslonik; qui met en place les voies de communication entre
+le noeud fournisseur et le nouveau noeud. </para> </listitem>
<listitem><para> <filename> step3-subscribe-sets.slonik </filename> </para>
-<para> A &lslonik; script to request subscriptions for all replications sets.</para> </listitem>
+<para> Un script &lslonik; qui demande la souscriptions à tous les ensembles de
+réplications.</para> </listitem>
</itemizedlist>
-<para> For testing purposes, this is sufficient to get a new node working. The configuration may not necessarily reflect what is desired as a final state:</para>
+<para> Lorsque l'on effectue un test, cela est suffisant pour faire fonctionner
+un nouveau noeud. La configuration ne doit pas forcément correspondre à une
+configuration finale, notamment :</para>
<itemizedlist>
-<listitem><para> Additional communications paths may be desirable in order to have redundancy. </para> </listitem>
-<listitem><para> It is assumed, in the generated scripts, that the new node should support forwarding; that may not be true. </para> </listitem>
-<listitem><para> It may be desirable later, after the subscription process is complete, to revise subscriptions. </para> </listitem>
+<listitem><para> Il est souhaitable de construire des voies de communication
+supplémentaires afin d'assurer leur redondance. </para> </listitem>
+<listitem><para> Les scripts générés supposent que le nouveau noeud doit
+être un noeud transmetteur ("forwarding"); ce qui n'est pas forcément vrai. </para> </listitem>
+<listitem><para> Il est parfois souhaitable, une fois que le processus d'abonnement
+est réalisé complètement, de modifier les abonnements. </para> </listitem>
</itemizedlist>
</sect2>
-</sect1>
-
+</sect1>
\ No newline at end of file
More information about the Trad
mailing list