Changeset 1124

Show
Ignore:
Timestamp:
08/23/08 10:20:41 (3 months ago)
Author:
daamien
Message:

slony : adminscripts.xml : a relire

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/adminscripts.xml

    r1123 r1124  
    371371</listitem> 
    372372 
    373 <listitem><para><envar>LOGHOME </envar> indicates the 
    374 <quote>home</quote> directory for log storage.</para> 
    375  
    376 <para> This script does not assume the use of the Apache log rotator 
    377 to manage logs; in that &postgres; version 8 does its own log 
    378 rotation, it seems undesirable to retain a dependancy on specific log 
    379 rotation <quote>technology.</quote> </para></listitem> 
    380  
    381 <listitem><para><envar>CLUSTERS</envar> is a list of &slony1; clusters 
    382 under management. </para></listitem> 
    383  
    384 </itemizedlist> 
    385  
    386 <para> In effect, you could run this every five minutes, and it would 
    387 launch any missing &lslon; processes. </para> 
     373<listitem><para><envar>LOGHOME </envar> indique le répertoire 
     374<quote>home</quote> pour le stockage des journaux applicatifs.</para> 
     375 
     376<para> Ce script ne nécessite pas l'utilisation de gestionnaire de logs d'Apache, 
     377sachant que &postgres; version 8 gÚre lui-même la rotation des logs, 
     378il semble inopportun de garder une dépendance à une <quote>technologie</quote> 
     379de rotation spécifique. </para></listitem> 
     380 
     381<listitem><para><envar>CLUSTERS</envar> est la liste des slusters &slony1; qui sont gérés. 
     382</para></listitem> 
     383 
     384</itemizedlist> 
     385 
     386<para> En pratique, vous pouvez lancer ce programme toutes les cinq minutes, et il relancera tous 
     387les processus &lslon; manquants. </para> 
    388388</sect2> 
    389389 
    …… 
    392392<indexterm><primary>script - slony1_extract_schema.sh</primary></indexterm> 
    393393 
    394 <para> You may find that you wish to create a new node some time well 
    395 after creating a cluster.  The script <filename> 
    396 slony1_extract_schema.sh </filename> will help you with this.</para> 
    397  
    398 <para> A command line might look like the following:</para> 
     394<para> Si vous souhaiterez créer un nouveau noeud, aprÚs la création du cluster, le script  <filename> 
     395slony1_extract_schema.sh </filename> vous aidera dans cette tache.</para> 
     396 
     397<para> La commande d'exécution peut ressembler à la ligne suivante :</para> 
    399398 
    400399<para><command> PGPORT=5881 PGHOST=master.int.example.info ./slony1_extract_schema.sh payroll payroll temppayroll </command> </para> 
    401400 
    402 <para> It performs the following:</para> 
    403  
    404 <itemizedlist> 
    405 <listitem><para> It dumps the origin node's schema, including the data in the &slony1; cluster schema. </para> 
    406  
    407 <para> Note that the extra environment variables <envar>PGPORT</envar> 
    408 and <envar>PGHOST</envar> to indicate additional information about 
    409 where the database resides. </para></listitem> 
    410  
    411 <listitem><para> This data is loaded into the freshly created temporary database, <envar>temppayroll</envar> </para> </listitem> 
    412 <listitem><para> The table and sequence OIDs in &slony1; tables are corrected   to point to the temporary database's configuration.  </para> </listitem> 
    413 <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> 
    414 <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> 
     401<para> Elle réalise les actions suivantes :</para> 
     402 
     403<itemizedlist> 
     404<listitem><para> Elle fait un dump du schéma du noeud origine, y compris les informations du schéma  
     405du cluster &slony1;. </para> 
     406 
     407<para> Notons que les variables d'environnement <envar>PGPORT</envar> 
     408et <envar>PGHOST</envar> fournissent des informations additionnelles sur l'emplacement de la 
     409base de données. </para></listitem> 
     410 
     411<listitem><para> Ces informations sont chargées dans une table temporaire fraichement créée : <envar>temppayroll</envar> </para> </listitem> 
     412<listitem><para> Les OIDs de table et de séquence dans les tables &slony1; sont corrigées pour 
     413pointer vers la configuration de la base temporaire. </para> </listitem> 
     414<listitem><para>  Un script slonik est lancé pour effecter l'action <xref linkend="stmtuninstallnode"/>  
     415sur la base temporaire. Ceci élimine toutes les tables et le schéma spécifique à &slony1;  
     416et supprime les triggers &slony1; des tables répliquées. </para> </listitem> 
     417<listitem><para> Enfin, la commande <application>pg_dump</application> est lancée sur la base  
     418temporaire, et produit une copie nettoyée du schéma sur la sortie standard. </para> </listitem> 
    415419</itemizedlist> 
    416420 
    …… 
    420424<indexterm><primary>script - slony-cluster-analysis</primary></indexterm> 
    421425 
    422 <para> If you are running a lot of replicated databases, where there 
    423 are numerous &slony1; clusters, it can get painful to track and 
    424 document this.  The following tools may be of some assistance in this.</para> 
    425  
    426 <para> <application>slony-cluster-analysis.sh</application> is a shell 
    427 script intended to provide some over-time analysis of the 
    428 configuration of a &slony1; cluster.  You pass in the usual 
    429 <application>libpq</application> environment variables 
     426<para> Si vous exploitez beaucoup de bases répliquées, au sein de plusieurs clusters &slony1;, 
     427il peut devenir pénible de suivre et de documenter votre architecture.  
     428L'outil suivant peut vous y aider.</para> 
     429 
     430<para> <application>slony-cluster-analysis.sh</application> est un script shell 
     431conçu pour fournir une analyse à long terme de la configuration d'un cluster 
     432&slony1;.  Vous passez les variables d'environnement  
     433<application>libpq</application> habituelles 
    430434(<envar>PGHOST</envar>, <envar>PGPORT</envar>, 
    431 <envar>PGDATABASE</envar>, and such) to connect to a member of a 
    432 &slony1; cluster, and pass the name of the cluster as an argument.</para> 
    433  
    434 <para> The script then does the following:</para> 
    435 <itemizedlist> 
    436 <listitem><para> Runs a series of queries against the &slony1; tables to get lists of nodes, paths, sets, and tables. </para> </listitem> 
    437 <listitem><para> This is stowed in a temporary file in <filename>/tmp</filename> </para> </listitem> 
    438 <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> 
    439 <listitem><para> If the configuration has changed, the old configuration file is renamed to indicate when the script noticed the change. </para></listitem> 
    440 <listitem><para> Ultimately, the current configuration is stowed in <envar>LOGDIR</envar> in a filename like <filename>cluster.last </filename> </para> </listitem> 
    441 </itemizedlist> 
    442  
    443 <para> There is a sample <quote>wrapper</quote> script, 
    444 <filename>slony-cluster-analysis-mass.sh</filename>, which sets things 
    445 up to point to a whole bunch of &slony1; clusters.</para> 
    446  
    447 <para> This should make it easier for a group of DBAs to keep track of 
    448 two things: </para> 
    449  
    450 <itemizedlist> 
    451  
    452 <listitem><para> Documenting the current state of system 
    453 configuration.  </para></listitem> 
    454  
    455 <listitem><para> Noticing when configuration 
    456 changes. </para></listitem> 
     435<envar>PGDATABASE</envar>, et ainsi de suite) pour se connecter à un membre du cluster 
     436&slony1;, et passer le nom du cluster comme argument.</para> 
     437 
     438<para> Le script effectue alors les actions suivantes :</para> 
     439<itemizedlist> 
     440<listitem><para> Lancement d'une séries de requêtes sur les tables &slony1; pour obtenir la liste des 
     441noeuds, des voies de communication, des ensembles de réplication et des tables. 
     442 </para> </listitem> 
     443<listitem><para> Ces données sont stockées dans un fichier temporaire situé dans <filename>/tmp</filename> </para> </listitem> 
     444<listitem><para> Une comparaison est effectuée entre la configuration présente et la configuration 
     445trouvée lors de la derniÚre exécution du script. Si la configuration a changé, un courriel contenant 
     446les différences ( produit avec <application>diff</application>)  
     447est envoyée à l'adresse spécifiée. </para> </listitem> 
     448<listitem><para> Si la configuration a changé, l'ancien fichier de configuration est renommé  
     449pour indiquer quand le script a remarqué le changement. </para></listitem> 
     450<listitem><para> Finalement, la configuration courante est stockée dans le dossier  
     451<envar>LOGDIR</envar> dans un fichier nommé <filename>cluster.last </filename> </para> </listitem> 
     452</itemizedlist> 
     453 
     454<para> Il existe une exemple de script <quote>wrapper</quote>, 
     455<filename>slony-cluster-analysis-mass.sh</filename>, qui permet de 
     456pointer vers un ensemble de clusters &slony1;.</para> 
     457 
     458<para> Ceci devrait simplifier la taches des administrateurs ("DBA") sur deux plans : </para> 
     459 
     460<itemizedlist> 
     461 
     462<listitem><para> La documentation de l'état courant du systÚme. 
     463</para></listitem> 
     464 
     465<listitem><para> La surveillance des changements de configuration. </para></listitem> 
    457466</itemizedlist> 
    458467 
    459468</sect2> 
    460469 
    461 <sect2 id="configurereplication"> <title> Generating slonik scripts 
    462 using <filename>configure-replication.sh</filename> </title> 
    463  
    464 <indexterm><primary> generate slonik scripts for a cluster </primary></indexterm> 
    465  
    466 <para> The <filename>tools</filename> script 
    467 <filename>configure-replication.sh</filename> is intended to automate 
    468 generating slonik scripts to configure replication.  This script is 
    469 based on the configuration approach taken by the <xref 
     470<sect2 id="configurereplication"> <title> Génération de scripts slonik avec 
     471<filename>configure-replication.sh</filename> </title> 
     472 
     473<indexterm><primary> générer des scripts slonik pour un cluster </primary></indexterm> 
     474 
     475<para> Le script  
     476<filename>configure-replication.sh</filename>, situé dans le répertoire <filename>outil</filename>, 
     477est conçu pour automatiser la génération de scripts slonik de configuration de la 
     478réplication. La configuration de ce script reprend  la même approche que le <xref 
    470479linkend="testbed"/>.</para> 
    471480 
    472 <para> This script uses a number (possibly large, if your 
    473 configuration needs to be particularly complex) of environment 
    474 variables to determine the shape of the configuration of a cluster. 
    475 It uses default values extensively, and in many cases, relatively few 
    476 environment values need to be set in order to get a viable 
    477 configuration. </para> 
    478  
    479 <sect3><title>Global Values</title> 
    480  
    481 <para> There are some values that will be used universally across a 
    482 cluster: </para> 
     481<para> Ce script utilise beaucoup ( peut-être énormément, si votre configuration 
     482est particuliÚrement complexe) de variables d'environnement pour déterminer 
     483la forme de la configuration du cluster. Il utilise massivement les valeurs par 
     484défaut, et dans la plupart des cas, peu de valeurs doivent être positionnées  
     485afin d'obtenir une configuration viable. </para> 
     486 
     487<sect3><title>Valeurs Globales</title> 
     488 
     489<para> Certaines valeurs sont utilisées universellement partout sur le cluster : </para> 
    483490 
    484491<variablelist> 
    485492<varlistentry><term><envar>  CLUSTER </envar></term> 
    486 <listitem><para> Name of Slony-I cluster</para></listitem></varlistentry> 
     493<listitem><para> Le nom du cluster Slony-I </para></listitem></varlistentry> 
    487494<varlistentry><term><envar>  NUMNODES </envar></term> 
    488 <listitem><para> Number of nodes to set up</para></listitem></varlistentry> 
     495<listitem><para> Le nombre de noeuds à configurer</para></listitem></varlistentry> 
    489496 
    490497<varlistentry><term><envar>  PGUSER </envar></term> 
    491 <listitem><para> name of PostgreSQL superuser controlling replication</para></listitem></varlistentry> 
     498<listitem><para> Le nom du super-utilisateur qui controle la réplication</para></listitem></varlistentry> 
    492499<varlistentry><term><envar>  PGPORT </envar></term> 
    493 <listitem><para> default port number</para></listitem></varlistentry> 
     500<listitem><para> Le numéro du port par défault</para></listitem></varlistentry> 
    494501<varlistentry><term><envar>  PGDATABASE </envar></term> 
    495 <listitem><para> default database name</para></listitem></varlistentry> 
     502<listitem><para> Le nom de la base de données par défault</para></listitem></varlistentry> 
    496503 
    497504<varlistentry><term><envar>  TABLES </envar></term> 
    498 <listitem><para> a list of fully qualified table names (<emphasis>e.g.</emphasis> - complete with 
    499            namespace, such as <command>public.my_table</command>)</para></listitem></varlistentry> 
     505<listitem><para> une liste de noms complets de tables (<emphasis>par exemple</emphasis> - un nom 
     506incluant l'espace de noms tel que  <command>public.ma_table</command>)</para></listitem></varlistentry> 
    500507<varlistentry><term><envar>  SEQUENCES </envar></term> 
    501 <listitem><para> a list of fully qualified sequence names (<emphasis>e.g.</emphasis> - complete with 
    502            namespace, such as <command>public.my_sequence</command>)</para></listitem></varlistentry> 
     508<listitem><para> une liste de noms complets de séquences (<emphasis>par exemple</emphasis> - un nom 
     509incluant l'espace de noms tel que  <command>public.ma_sequence</command>)</para></listitem></varlistentry> 
    503510 
    504511</variablelist> 
    505512 
    506 <para>Defaults are provided for <emphasis>all</emphasis> of these 
    507 values, so that if you run 
    508 <filename>configure-replication.sh</filename> without setting any 
    509 environment variables, you will get a set of slonik scripts.  They may 
    510 not correspond, of course, to any database you actually want to 
    511 use...</para> 
    512 </sect3> 
    513  
    514 <sect3><title>Node-Specific Values</title> 
    515  
    516 <para>For each node, there are also four environment variables; for node 1: </para> 
     513<para>Des valeurs par défaults sont fournies pour <emphasis>chacune</emphasis> de ces valeurs, 
     514si bien que si vous lancez <filename>configure-replication.sh</filename>  
     515sans configurer aucune variable d'environnement, vous obtiendrez 
     516un ensemble de scripts slonik. 
     517Bien sûr, ils ne correspondront pas aux bases que vous voudrez configurer...</para> 
     518</sect3> 
     519 
     520<sect3><title>Valeur spécifique à un noeud</title> 
     521 
     522<para>Pour chaque node, il y a également quatre variables d'environnement;  
     523pour le noeud 1: </para> 
    517524<variablelist> 
    518525<varlistentry><term><envar>  DB1 </envar></term> 
    519 <listitem><para> database to connect to</para></listitem></varlistentry> 
     526<listitem><para> La base de données à laquelle les scripts  
     527doivent se connecter</para></listitem></varlistentry> 
    520528<varlistentry><term><envar>  USER1 </envar></term> 
    521 <listitem><para> superuser to connect as</para></listitem></varlistentry> 
     529<listitem><para> Le super-utilisateur utilisé pour la connexion</para></listitem></varlistentry> 
    522530<varlistentry><term><envar>  PORT1 </envar></term> 
    523 <listitem><para> port</para></listitem></varlistentry> 
     531<listitem><para> Le port</para></listitem></varlistentry> 
    524532<varlistentry><term><envar>  HOST1 </envar></term> 
    525 <listitem><para> host</para></listitem></varlistentry> 
     533<listitem><para> L'hÃŽte</para></listitem></varlistentry> 
    526534</variablelist> 
    527535 
    528 <para> It is quite likely that <envar>DB*</envar>, 
    529 <envar>USER*</envar>, and <envar>PORT*</envar> should be drawn from 
    530 the global <envar>PGDATABASE</envar>, <envar>PGUSER</envar>, and 
    531 <envar>PGPORT</envar> values above; having the discipline of that sort 
    532 of uniformity is usually a good thing.</para> 
    533  
    534 <para> In contrast, <envar>HOST*</envar> values should be set 
    535 explicitly for <envar>HOST1</envar>, <envar>HOST2</envar>, ..., as you 
    536 don't get much benefit from the redundancy replication provides if all 
    537 your databases are on the same server!</para> 
    538  
    539 </sect3> 
    540  
    541 <sect3><title>Resulting slonik scripts</title> 
    542  
    543 <para> slonik config files are generated in a temp directory under 
    544 <filename>/tmp</filename>.  The usage is thus:</para> 
    545  
    546 <itemizedlist> 
    547  
    548 <listitem> <para><filename>preamble.slonik</filename> is a 
    549 <quote>preamble</quote> containing connection info used by the other 
    550 scripts.</para> 
    551  
    552 <para> Verify the info in this one closely; you may want to keep this 
    553 permanently to use with future maintenance you may want to do on the 
    554 cluster.</para></listitem> 
     536<para> Il est trÚs probable que <envar>DB*</envar>, 
     537<envar>USER*</envar>, et <envar>PORT*</envar> correspondent aux 
     538variables globales <envar>PGDATABASE</envar>, <envar>PGUSER</envar>, et 
     539<envar>PGPORT</envar> décrites précédemment;  
     540Conserver cette correspondance est souvent une bonne chose.</para> 
     541 
     542<para> En revanche, Les valeurs <envar>HOST*</envar> doivent être définies 
     543explicitement pour <envar>HOST1</envar>, <envar>HOST2</envar>, ...,  
     544car il n'est pas trÚs malin de mettre en place un systÚme de réplication 
     545si toutes les bases redondantes se trouvent sur le même serveur !</para> 
     546 
     547</sect3> 
     548 
     549<sect3><title>Les scripts slonik générés</title> 
     550 
     551<para> Les scripts de configuration slonik sont générés dans un repertoire 
     552temporaire à l'intérieur de <filename>/tmp</filename>.   
     553Leur usage est le suivant :</para> 
     554 
     555<itemizedlist> 
     556 
     557<listitem> <para><filename>preamble.slonik</filename> est un fichier 
     558<quote>preambule</quote> contenant les informations de connexion utilisées 
     559par les autres scripts.</para> 
     560 
     561<para> Vérifier attentivement celui-ci; vous pourrez le réutiliser pour 
     562les futures opérations de maintenance que vous effectuerez sur le cluster. 
     563</para></listitem> 
    555564 
    556565<listitem><para> <filename>create_set.slonik</filename></para> 
    557566 
    558 <para>This is the first script to run; it sets up the requested nodes 
    559 as being &slony1; nodes, adding in some &slony1;-specific config 
    560 tables and such.</para> 
    561  
    562 <para>You can/should start slon processes any time after this step has 
    563 run.</para></listitem> 
     567<para>Ce script est le premier qu'il faut lancer; il paramÚtre les noeuds 
     568spécifiés en noeud &slony1;, en y ajoutant les tables et les autres objets  
     569spécifiques de &slony1;. 
     570</para> 
     571 
     572<para>Vous pouvez/devez lancer les processus slon juste aprÚs cette étape.</para></listitem> 
    564573 
    565574<listitem><para><filename>  store_paths.slonik</filename></para> 
    566575 
    567 <para> This is the second script to run; it indicates how the &lslon;s 
    568 should intercommunicate.  It assumes that all &lslon;s can talk to all 
    569 nodes, which may not be a valid assumption in a complexly-firewalled 
    570 environment.  If that assumption is untrue, you will need to modify 
    571 the script to fix the paths.</para></listitem> 
     576<para> Le second script à exécuter; il indique comment 
     577les &lslon;s doivent communiquer entre eux. Ce script suppose que 
     578tous les &lslon; peuvent parler à tous les noeuds, ce qui n'est peut-être 
     579exact dans un environnement peuplé de pare-feux complexes. Si cette supposition 
     580n'est pas correcte, vous devez modifier ce script pour corriger les voies de 
     581communications.</para></listitem> 
    572582 
    573583<listitem><para><filename>create_set.slonik</filename></para> 
    574584 
    575 <para> This sets up the replication set consisting of the whole bunch 
    576 of tables and sequences that make up your application's database 
    577 schema.</para> 
    578  
    579 <para> When you run this script, all that happens is that triggers are 
    580 added on the origin node (node #1) that start collecting updates; 
    581 replication won't start until #5...</para> 
    582  
    583 <para>There are two assumptions in this script that could be 
    584 invalidated by circumstances:</para> 
    585  
    586 <itemizedlist> 
    587      <listitem><para> That all of the tables and sequences have been 
    588      included.</para> 
    589  
    590      <para> This becomes invalid if new tables get added to your 
    591      schema and don't get added to the <envar>TABLES</envar> 
    592      list.</para> </listitem> 
    593  
    594      <listitem><para> That all tables have been defined with primary 
    595      keys.</para> 
    596  
    597      <para> Best practice is to always have and use true primary keys. 
    598      If you have tables that require choosing a candidate primary key 
    599      or that require creating a surrogate key using <xref 
    600      linkend="stmttableaddkey"/>, you will have to modify this script 
    601      by hand to accomodate that. </para></listitem> 
     585<para> Ce script configure l'ensemble de réplication composé de toutes 
     586les tables et les séquences présente dans le schéma de la base de données 
     587de votre application.</para> 
     588 
     589<para> Lorsque vous lancez ce script, la seule actions menées est  
     590l'ajout de triggers sur le noeud origine (noeud #1) qui vont commencer  
     591à collecter les mises à jours. La réplication ne commencera qu'à  
     592l'étape  #5...</para> 
     593 
     594<para>Il y a deux suppositions dans ce scripts qui peuvent ne pas être 
     595valides dans certaines circonstances:</para> 
     596 
     597<itemizedlist> 
     598     <listitem><para> que toutes les tables et les séquences soit répliquées.</para> 
     599 
     600     <para> Ceci n'est pas valide lorsque de nouvelles tables  
     601        sont ajoutée dans votre schéma et qu'elles ne sont pas ajoutées 
     602        dans le liste  <envar>TABLES</envar>.</para> </listitem> 
     603 
     604     <listitem><para> que toutes les tables sont définies avec des clefs primaires.</para> 
     605 
     606     <para> La bonne pratique est de toujours créer et utiliser de vraies clefs 
     607        primaires. 
     608 
     609     Si vous avez des tables qui nécessite de choisir une clef primaire candidate ou 
     610qui nécessite la création d'une clef additionnelle avec la commande <xref 
     611     linkend="stmttableaddkey"/>, vous devez modifier ce script à la main pour l'accomoder. 
     612 </para></listitem> 
    602613 
    603614</itemizedlist> 
    …… 
    606617<listitem><para> <filename> subscribe_set_2.slonik </filename></para> 
    607618 
    608   <para> And 3, and 4, and 5, if you set the number of nodes 
    609   higher... </para> 
    610  
    611   <para> This is the step that <quote>fires up</quote> 
    612   replication.</para> 
    613  
    614   <para> The assumption that the script generator makes is that all 
    615   the subscriber nodes will want to subscribe directly to the origin 
    616   node.  If you plan to have <quote>sub-clusters,</quote> perhaps 
    617   where there is something of a <quote>master</quote> location at each 
    618   data centre, you may need to revise that.</para> 
    619  
    620   <para> The slon processes really ought to be running by the time you 
    621   attempt running this step.  To do otherwise would be rather 
    622   foolish.</para> </listitem> 
     619  <para> et 3,  4,  5, si vous configurez d'autres noeuds... </para> 
     620 
     621  <para> Ceci est l'étape qui <quote>déclenche</quote> 
     622  réplication.</para> 
     623 
     624  <para> Ce script fait la supposition que tous les noeuds abonnés voudront 
     625s'abonner directement au noeud origine. Si vous souhaitez mettre en place  
     626des <quote>sous-clusters</quote>,avec peut-être un noeud maître dans chaque 
     627datacenter, vous devez modifier ces scripts.</para> 
     628 
     629<para> Les processus slon doivent fonctionner au moment ou vous réaliser cette 
     630étape. Il est abusrde de lancer ces scripts lorsque ce n'est pas le cas. 
     631</para> </listitem> 
    623632</itemizedlist> 
    624633 
    …… 
    627636 
    628637<sect2 id="bsd-ports-profile"> <title> <filename> slon.in-profiles </filename> </title> 
    629 <subtitle> Apache-Style profiles for FreeBSD <filename>ports/databases/slony/*</filename> </subtitle> 
    630  
    631 <indexterm><primary> Apache-style profiles for FreeBSD </primary> <secondary>FreeBSD </secondary> </indexterm> 
    632  
    633 <para> In the <filename>tools</filename> area, <filename>slon.in-profiles</filename> is a 
    634 script that might be used to start up &lslon; instances at the time of 
    635 system startup.  It is designed to interact with the FreeBSD Ports 
    636 system.</para> 
     638<subtitle> profiles dans le style d'Apache pour FreeBSD <filename>ports/databases/slony/*</filename> </subtitle> 
     639 
     640<indexterm><primary> prfiles dans le style d'Apache pour FreeBSD </primary> <secondary>FreeBSD </secondary> </indexterm> 
     641 
     642<para> Dans le répertoire  <filename>tools</filename>, le script <filename>slon.in-profiles</filename> permet de lancer des instances 
     643&lslon; lors du démarrage du systÚme. Il est conçu pour interagir avec 
     644systÚmes des ports de FreeBSD.</para> 
    637645 
    638646</sect2> 
    …… 
    640648 
    641649<sect2 id="duplicate-node"> <title> <filename> duplicate-node.sh </filename> </title> 
    642 <indexterm><primary> duplicating nodes </primary> </indexterm> 
    643 <para> In the <filename>tools</filename> area, 
    644 <filename>duplicate-node.sh</filename> is a script that may be used to 
    645 help create a new node that duplicates one of the ones in the 
    646 cluster. </para> 
    647  
    648 <para> The script expects the following parameters: </para> 
    649 <itemizedlist> 
    650 <listitem><para> Cluster name </para> </listitem> 
    651 <listitem><para> New node number </para> </listitem> 
    652 <listitem><para> Origin node </para> </listitem> 
    653 <listitem><para> Node being duplicated </para> </listitem> 
    654 <listitem><para> New node </para> </listitem> 
    655 </itemizedlist> 
    656  
    657 <para> For each of the nodes specified, the script offers flags to 
    658 specify <function>libpq</function>-style parameters for 
     650<indexterm><primary> dupliquer un noeud </primary> </indexterm> 
     651<para> Dans le répertoire <filename>tools</filename>, le script 
     652<filename>duplicate-node.sh</filename> aide à créer un nouveau noeud 
     653en dupliquant un des noeuds du cluster. 
     654</para> 
     655 
     656<para> Ce script attend les paramÚtres suivants : </para> 
     657<itemizedlist> 
     658<listitem><para> Le nom du cluster</para> </listitem> 
     659<listitem><para> Le numéro du nouveau noeud </para> </listitem> 
     660<listitem><para> Le noeud origine </para> </listitem> 
     661<listitem><para> Le noeud répliqué </para> </listitem> 
     662<listitem><para> Le nouveau noeud </para> </listitem> 
     663</itemizedlist> 
     664 
     665<para> Pour chaque noeud spécifié, le scripts permet de préciser 
     666les paramÚtres de type <function>libpq</function> pour  
    659667<envar>PGHOST</envar>, <envar>PGPORT</envar>, 
    660 <envar>PGDATABASE</envar>, and <envar>PGUSER</envar>; it is expected 
    661 that <filename>.pgpass</filename> will be used for storage of 
    662 passwords, as is generally considered best practice. Those values may 
    663 inherit from the <function>libpq</function> environment variables, if 
    664 not set, which is useful when using this for testing.  When 
    665 <quote>used in anger,</quote> however, it is likely that nearly all of 
    666 the 14 available parameters should be used. </para> 
    667  
    668 <para> The script prepares files, normally in 
    669 <filename>/tmp</filename>, and will report the name of the directory 
    670 that it creates that contain SQL and &lslonik; scripts to set up the 
    671 new node. </para> 
     668<envar>PGDATABASE</envar>, et <envar>PGUSER</envar>; Le fichier  
     669<filename>.pgpass</filename> peut être utilisé pour le stockage  
     670des mots de passe, ce qui est généralement considéré comme une  
     671bonne pratique. Lorsqu'elle ne sont pas définie, ces valeurs peuvent  
     672hériter des variables d'environnement <function>libpq</function>, 
     673ce qui est pratique quand on réalise des tests. Toutefois 
     674lorsque que ce script est utilisé <quote>de maniÚre brutale</quote>, 
     675il est souvent nécessaire de définir les 14 paramÚtres disponibles. 
     676</para> 
     677 
     678<para> Ce script prépare des fichiers, placés dans  
     679<filename>/tmp</filename>, et annonce le nom du répertoire  
     680qu'il a créé pour les scripts SQL et &lslonik; de configuration  
     681du nouveau noeud. </para> 
    672682 
    673683<itemizedlist> 
    674684<listitem><para> <filename> schema.sql </filename> </para>  
    675 <para> This is drawn from the origin node, and contains the <quote>pristine</quote> database schema that must be applied first.</para></listitem> 
     685<para> Ce script est tiré du noeud origine et contient le schéma  
     686de données <quote>originel</quote> qui doit être appliqué au départ.</para></listitem> 
    676687<listitem><para> <filename> slonik.preamble </filename> </para>  
    677688 
    678 <para> This <quote>preamble</quote> is used by the subsequent set of slonik scripts. </para> </listitem> 
     689<para> Ce fichier <quote>preamble</quote> est utilisé par l'ensemble des scripts slonik ci-dessous. </para> </listitem> 
     690 
    679691<listitem><para> <filename> step1-storenode.slonik </filename> </para>  
    680 <para> A &lslonik; script to set up the new node. </para> </listitem> 
     692<para> Un script &lslonik; qui configure le nouveau noeud.<para> </listitem> 
    681693<listitem><para> <filename> step2-storepath.slonik </filename> </para>  
    682 <para> A &lslonik; script to set up path communications between the provider node and the new node. </para> </listitem> 
     694<para> Un script &lslonik; qui met en place les voies de communication entre 
     695le noeud fournisseur et le nouveau noeud. </para> </listitem> 
    683696<listitem><para> <filename> step3-subscribe-sets.slonik </filename> </para>  
    684 <para> A &lslonik; script to request subscriptions for all replications sets.</para> </listitem> 
    685 </itemizedlist> 
    686  
    687 <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> 
    688  
    689 <itemizedlist> 
    690 <listitem><para> Additional communications paths may be desirable in order to have redundancy. </para> </listitem> 
    691 <listitem><para> It is assumed, in the generated scripts, that the new node should support forwarding; that may not be true. </para> </listitem> 
    692 <listitem><para> It may be desirable later, after the subscription process is complete, to revise subscriptions. </para> </listitem> 
     697<para> Un script &lslonik; qui demande la souscriptions à tous les ensembles de 
     698réplications.</para> </listitem> 
     699</itemizedlist> 
     700 
     701<para> Lorsque l'on effectue un test, cela est suffisant pour faire fonctionner  
     702un nouveau noeud. La configuration ne doit pas forcément correspondre à une 
     703configuration finale, notamment :</para> 
     704 
     705<itemizedlist> 
     706<listitem><para> Il est souhaitable de construire des voies de communication  
     707supplémentaires afin d'assurer leur redondance. </para> </listitem> 
     708<listitem><para> Les scripts générés supposent que le nouveau noeud doit 
     709être un noeud transmetteur ("forwarding"); ce qui n'est pas forcément vrai. </para> </listitem> 
     710<listitem><para> Il est parfois souhaitable, une fois que le processus d'abonnement 
     711est réalisé complÚtement, de modifier les abonnements. </para> </listitem> 
    693712</itemizedlist> 
    694713 
    695714</sect2> 
    696715</sect1> 
    697