root/traduc/trunk/slony/adminscripts.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- DerniÚre modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->

<sect1 id="adminscripts">
  <title>Scripts d'administration</title>

  <indexterm><primary>scripts d'administration de &slony1;</primary></indexterm>

  <para> Un certain nombre de scripts ont été développes tout au long de l'histoire de
        &slony1; pour aider les utilisateurs à gérer leurs clusters. Cette section ainsi
        que celle sur le <xref linkend="monitoring"/> et la  <xref
  linkend="maintenance"/> décrit leur utilisation. </para>

  <sect2 id="altperl"> <title>Les scripts altperl</title>

    <indexterm><primary> Script altperl pour &slony1;</primary></indexterm>

    <para>Il existe un ensemble de scripts qui simplifie l'administration de plusieurs 
    instances &slony1;. Ces scripts supportent une nombre variable de noeuds. Ils peuvent
    être installés pendant le processus d'installation :</para>

    <para><command> ./configure --with-perltools</command></para>

    <para>Ceci va produire un certain nombre de scripts avec le préfixe 
    <command>slonik_</command>.  Ils éliminent les risques de confusion en se référençant
    à un fichier central de configuration qui contient les détails de la configuration 
    de votre site. Un exemple documenté de ce fichier est fourni dans 
    <filename>altperl/slon_tools.conf-sample</filename>. La plupart dispose également
    une aide en ligne grâce à l'option "--help", ce qui les rend plus facile à prendre en main
    et à utiliser.</para>

    <para>La plupart des scripts de génération Slonik utilise la sortie STDOUT. 
    Pendant un temps, les commandes étaient passées directement à <xref linkend="slonik"/>
    pour qu'il les exécute. Malheureusement, il s'agit d'une méthode trop . 
    <quote>agressive</quote>, car de légÚres coquilles dans la ligne de commande 
    peuvent conduire, dans certains cas, Ã  des situations calamiteuses.
    Tout administrateur qui se respecte doit relire le script 
    <emphasis>avant</emphasis> de l'envoyer à <xref linkend="slonik"/>.</para>

    <sect3><title>Gestion de multiples clusters</title>
      <indexterm><primary>Gérer de multiples clusters avec les outils altperl</primary></indexterm>

      <para>La variable d'environnement <envar>SLONYNODES</envar> est utilisée pour déterminer
      quel fichier de configuration Perl sera utilisé pour controler les noeuds du cluster
      &slony1;. Si elle n'est pas fournie le fichier  <filename>slon_tools.conf</filename> 
      situé dans l'emplacement par défaut sera utilisé. </para>

      <para>Voici la liste des variables qui peuvent être configurées :
      <itemizedlist>

        <listitem><para><envar>$CLUSTER_NAME</envar>=orglogs;   # Quel est le nom du cluster de réplication ?</para></listitem>
        <listitem><para><envar>$LOGDIR</envar>='/opt/OXRS/log/LOGDBS';  # Quel est le répertoire des logs ?</para></listitem>
        <listitem><para><envar>$APACHE_ROTATOR</envar>="/opt/twcsds004/OXRS/apache/rotatelogs";  # Si ce paramÚtre est défini, il indique où trouver le gestionnaire de logs d'Apache</para></listitem>
        <listitem><para><envar>foldCase</envar> # Si la valeur est 1, les noms d'objet ( y compris les noms de schéma) seront transformés en minuscule. Par défaut, les noms d'objets restent inchangés. Notons que &postgres; lui-même transforme les noms d'objets en minuscule;
        Si vous créez une table avec la commande <command> CREATE TABLE
        MA_TABLE (Id INTEGER, MoNChamp text);</command>, le résultat sera
        équivalent à <command> create table ma_table (id integer,
        monchamp text);</command>, le nom de la table et ses champs sera transformé en minuscule.
        </para>

        </listitem>
      </itemizedlist>
      </para>

      <para> Vous pouvez ensuite définir un ensemble de noeuds qui participeront à la réplication
      en utilisant plusieurs appels à la fonction <function>add_node()</function>.
      </para>

      <para><command>
        add_node (host => '10.20.30.40', dbname => 'orglogs', port => 5437,
                                user => 'postgres', node => 4, parent => 1);
      </command></para>

      <para>Les paramÚtres de la fonction <function>add_node()</function> sont les suivants :</para>

      <programlisting>
      my %PARAMS =   (host=> undef,             # nom de l'hÃŽte
                        dbname => 'template1',  # nom de la base
                      port => 5432,             # numéro du port
                      user => 'postgres',       # utilisateur de la connexion
                      node => undef,            # numéro du noeud
                      password => undef,        # mot de passe de l'utilisateur
                      parent => 1,              # l'identifiant du noeud pÚre
                      noforward => undef        # ce noeud doit-il retransmettre les modifications ?
                      sslmode => undef        # mode SSL - détermine la priorité 
                                              # d'utilisation de la couche SSL
                                              # = disable,allow,prefer,require
      );
      </programlisting>
    </sect3> 

    <sect3><title>Configuration d'un ensemble de réplication </title>
      <indexterm><primary>cluster.set1 - configuration d'un ensemble de réplication pour les outils
      Perl</primary></indexterm>

      <para>La variable d'environnement UNIX <envar>SLONYSET</envar> est utilisée pour déterminer
      quel fichier de configuration doit être lu pour connaître les objets qui sont contenus 
      dans un ensemble donné.</para>

      <para>Contrairement à <envar>SLONYNODES</envar>, qui est essentielle pour 
      <emphasis>tous</emphasis> les scripts de génération <xref linkend="slonik"/>,
      celle-ci n'est nécessaire que lorsqu'on exécute 
      <filename>create_set</filename>, car il s'agit du seul script qui contrÃŽle
      le placement des tables dans les différents ensemble de réplication.
      </para>

    </sect3>
    <sect3><title>slonik_build_env</title>
      <indexterm><primary>slonik_build_env</primary></indexterm>

      <para>Cette commande interroge la base de données et produit un résultat qui 
      peut être utilisé dans <filename>slon_tools.conf</filename>, notamment :</para>
      <itemizedlist>

      <listitem><para> une série d'appel à <function>add_node()</function> pour configurer 
      le cluster</para></listitem>
      <listitem><para> les tableaux <envar>@KEYEDTABLES</envar>,
      <envar>@SERIALT</envar>, et <envar>@SEQUENCES</envar></para></listitem>
      </itemizedlist>
    </sect3>
    <sect3><title>slonik_print_preamble</title>

      <para>Cette commande produit simplement le <quote>préambule</quote> qui est nécessaire
      Ã  chaque scripts slonik. En fait, elle fournit un <quote>squelette</quote> de script slonik
      qui ne fait pas d'action particuliÚre.</para>
    </sect3>
    <sect3><title>slonik_create_set</title>

      <para>Cette commande nécessite que les variables <envar>SLONYSET</envar> et 
      <envar>SLONYNODES</envar> soit configurées;
      Elle permet de produire le script <command>slonik</command> 
      qui configure un ensemble de réplication en décrivant les tables et les séquences
      qui seront répliquées.</para>
    </sect3>
    <sect3><title>slonik_drop_node</title>
      <para>Cette commande produit une script Slonik qui supprime une noeud du cluster &slony1; .</para>
    </sect3>
    <sect3><title>slonik_drop_set</title>
      <para>Cette commande produit un script Slonik qui supprime un ensemble de réplication
      (<emphasis>c'est à dire</emphasis> un groupe de tables et de séquences).</para>
    </sect3>

    <sect3 id="slonik-drop-table"><title>slonik_drop_table</title>
      <para>Cette commande produit un script Slonik qui supprime une table de la réplication.
      Elle nécessite en entrée l'identifiant de la table ( disponible dans le table
      <envar>sl_table</envar>). </para>
    </sect3>

    <sect3><title>slonik_execute_script</title>
      <para>Cette commande produit un script pour effectuer des changements DDL sur un ensemble 
      de réplication.</para>
    </sect3>

    <sect3><title>slonik_failover</title>
      <para>Cette commande produit un script qui demande une bascule d'urgence entre un noeud
      mort et une nouvelle origine</para>
    </sect3>
    <sect3><title>slonik_init_cluster</title>
      <para>Cette commande produit un script Slonik qui intialise un cluster &slony1; tout entier,
      y compris les noeuds, les voies de communications et les voies d'écoute.
      </para>
    </sect3>

    <sect3><title>slonik_merge_sets</title>
      <para>Cette commande produit un script Slonik qui fusionne deux ensembles de réplication.
      </para>
    </sect3>
    
    <sect3><title>slonik_move_set</title>
      <para>Cette commande produit un script Slonik qui déplace l'origine d'un ensemble de réplication vers un autre noeud.</para>
    </sect3>
    <sect3><title>réplication_test</title>

      <para>Ce script vérifie que &slony1; réplique correctement les données.</para>
    </sect3>
    <sect3><title>slonik_restart_node</title>

      <para>Cette commande produit un script Slonik que demande le redémarrage d'un noeud.
      Elle était particuliÚrement utile avant la version 1.0.5, lorsque les noeuds étaient
      bloqués suite à la mort du démon slon.</para>
    </sect3>
    <sect3><title>slonik_restart_nodes</title>

      <para>Cette commande produit un script Slonik qui redémarre tous les noeuds du cluster.
      Elle n'est pas trÚs utile.</para>
    </sect3>

    <sect3><title>slony_show_configuration</title>
      <para>Cette commande affiche la configuration de l'environnement (c'est à dire la variable <envar>SLONYNODES</envar>).</para>
    </sect3>

    <sect3><title>slon_kill</title>
      <para>Cette commande tue le chien de garde slony et tous les démons slon pour un
      ensemble de réplication donné. Elle ne fonctionne que si ces processus fonctionnent sur l'hÎte local, bien sûr !
      </para>
    </sect3>
    
    <sect3><title>slon_start</title>
      <para>Cette commande démarre le démon slon pour un cluster et un noeud donnés, elle utilise
      le chien de garde slon_watchdog pour s'assurer qu'il fonctionne.</para>
    </sect3>
    
    <sect3 id="slonwatchdog"><title>slon_watchdog</title>
      <para>Processus utilisé par <command>slon_start</command>.</para>
    </sect3>
    
    <sect3><title>slon_watchdog2</title>
      <para>Ce script est un chien de garde plus malin; il surveille un noeud donné et relance 
      le processus slon si il constate qu'aucune modification ne s'est produite depuis 20 minutes ou plus.</para>
      <para>Ceci est utile lorsqu'une connexion réseau est instable et que le démon slon s'arrête sans crier gare.</para>
    </sect3>
    
    <sect3><title>slonik_store_node</title>
      <para>Cette commande ajoute un noeud dans un cluster.</para>
    </sect3>
    
    <sect3><title>slonik_subscribe_set</title>
      <para>Ce script génÚre un script Slonik script pour abonner un noeud donné çà un ensemble donné.</para>
    </sect3>
    
    <sect3><title>slonik_uninstall_nodes</title>
      <para>Cette commande parcours le cluster et supprime le schéma &slony1; sur tous les noeuds;
      Vous pouvez utilisez cet outil si vous souhaitez détruire la réplication sur l'ensemble du cluster. Il s'agit d'un script <emphasis>TRÈS</emphasis> dangereux !</para>
    </sect3>
    
    <sect3><title>slonik_unsubscribe_set</title>
      <para>Cette commande produit un script Slonik qui désabonne un noeud d'un ensemble de réplication.</para>
    </sect3>
  
    <sect3><title>slonik_update_nodes</title>
      <para>Cette commande produit un script Slonik qui incite tous les noeuds à mettre à jour les fonctions &slony1;. Elle est utile lorsque l'on effectue un changement de version de &slony1;.</para>
    </sect3>
</sect2>
<sect2 id="mkslonconf"><title>mkslonconf.sh</title>
  <indexterm><primary>Générer le fichier slon.conf pour &slony1;</primary></indexterm>

  <para> Ce script shell est conçu parcourir un cluster &slony1; et 
  produire un ensemble de fichiers <filename>slon.conf</filename> 
  qui pourront être utilisé via l'option <command> slon -f slon.conf </command>.
  </para>

  <para> Lorsque toute la configuration est placée dans un fichier pour chaque &lslon;,
  on peut alors facilement les invoquer, sans risquer d'oublier l'option
  <command>-a</command>, ce qui peut provoquer le crash d'un noeud en mode
  <link linkend="logshipping"> log shipping </link>. </para>

  <para> Pour lancer le script, il faut configurer l'environnement de la maniÚre suivante :</para>

  <itemizedlist>
    <listitem><para> Tout d'abord, l'environnement doit être configuré avec les paramÚtres
      adéquats pour que libpq puisse se connecter à une des bases de données du cluster.
      Vous devez donc définir une combinaison parmi les variables d'environnement suivantes :
      </para>

      <itemizedlist>
        <listitem><para><envar>PGPORT</envar></para></listitem>
        <listitem><para><envar>PGDATABASE</envar></para></listitem>
        <listitem><para><envar>PGHOST</envar></para></listitem>
        <listitem><para><envar>PGUSER</envar></para></listitem>
        <listitem><para><envar>PGSERVICE</envar></para></listitem>
      </itemizedlist>
    </listitem>

    <listitem>
      <para> <envar>SLONYCLUSTER</envar> - le nom du cluster &slony1; qui 
      doit être <quote>parcouru</quote>.  </para>
    </listitem>

    <listitem>
      <para> <envar>MKDESTINATION</envar> - un répertoire qui accueillera
      la configuration; le script crée un dossier
      <filename>MKDESTINATION/$SLONYCLUSTER/conf</filename> pour les fichiers de configuration
      des démons &lslon; et un dossier
      <filename>MKDESTINATION/$SLONYCLUSTER/pid</filename> pour que &lslon; y stocke
      les fichiers PID. </para>
    </listitem>

    <listitem>
      <para> <envar>LOGHOME</envar> - un répertoire qui accueillera les fichiers
      de log; un dossier nommé 
      <command>$LOGHOME/$SLONYCLUSTER/node[numéro]</command> sera créé pour chaque noeud.</para>
    </listitem>
  
  </itemizedlist>
  <para> Pour chaque <quote>nouveau</quote> noeud qu'il découvre, ce script
  va créer un nouveau fichier de configuration &lslon;. </para>

  <warning>
    <para> Il est important de préciser que ce script présente quelques particularités 
    qu'il faut connaître, même aucune n'est vraiment surprenante.</para>

    <itemizedlist>
      <listitem>
        <para> Le DSN est positionné à la plus petite valeur trouvé pour
        chaque noeud dans le table <envar>sl_path</envar>.  Vous devrez probablement
        modifier cette valeur.</para>
      </listitem>

      <listitem>
        <para> Plusieurs paramÚtres sont initialisés avec leur valeur par défaut;
        Vous devrez probablement les réajuster à la main. </para>
      </listitem>

      <listitem>
        <para> Si vous exécutez les processus &lslon; sur de multiples noeuds (<emphasis>par exemple</emphasis> - si vous utilisez &slony1; à travers un réseau WAN),
        ce script va joyeusement créer des fichiers de configuration pour des
        &lslon;s que vous comptez lancer sur un hÎte différent.  </para>

        <para> Vérifiez bien quels noeuds sont configurés avant de redémarrer les &lslon;s.  </para>

        <para> En général, cela provoque des inconvénients mineurs,
        comme, par exemple, un &lslon; fonctionnant de maniÚre inapproprié,
         échouant suite à un problÚme de connectivité, (ce qui ne provoque pas
        de dégâts ! ), ou fonctionnant moins efficacement vu qu'il se trouve du mauvais
        coté du <quote>tuyau</quote>.</para>

        <para> D'un autre cÎté, si vous faites fonctionner un noeud en mode log shipping sur
        le site distant, l'arrivée d'un &lslon; que 
        <emphasis>ne collecte pas</emphasis> les logs peut ruiner une semaine complÚte d'activité. </para>
      </listitem>
    </itemizedlist>
  
  </warning>

  <para> Les fichiers produits par <filename>mkslonconf.sh</filename>
  sont spécifiquement conçu pour gérer des &lslon;s sur de multiples clusters
  avec le script décrit dans la section suivante... </para>

</sect2>

<sect2 id="launchclusters"><title> launch_clusters.sh </title>

  <indexterm><primary>lancer un cluster &slony1; cluster en utilisant les fichiers slon.conf </primary></indexterm>

  <para> Voici un autre script shell qui utilise la configuration produite
  par <filename>mkslonconf.sh</filename> et qui peut être utilisé lors du 
  démarrage du systÚme, à la suite des processus <filename>rc.d</filename>,
  ou dans un processus cron, pour s'assurer que les processus &lslon; 
  fonctionnent.</para>

  <para> Il utilise les variables d'environnement suivantes :</para>

  <itemizedlist>

    <listitem><para><envar>PATH</envar> qui doit contenir, de préférence au début, le
    chemin vers les binaires &lslon; qui doivent être exécutés.</para></listitem>

    <listitem><para><envar>SLHOME</envar> indique le répertoire
      <quote>home</quote> qui contient les fichiers de configuration de &lslon;;
      ces fichiers doivent être rangés en sous-répertoires, un pour chaque cluster,
      avec un nom de fichier du type <filename>node1.conf</filename>,
      <filename>node2.conf</filename>, et ainsi de suite. </para>

      <para> Le script utilise la commande <command>find $SLHOME/$cluster/conf
      -name "node[0-9]*.conf"</command> pour trouver les fichiers de configuration &lslon;.</para>

      <para> Si vous déplacez ces fichiers, ou si vous les renommez, ils ne seront pas trouvés;
      c'est une façon trÚs simple de supprimer des noeuds.</para>
    </listitem>

    <listitem>
      <para><envar>LOGHOME </envar> indique le répertoire 
      <quote>home</quote> pour le stockage des journaux applicatifs.</para>

      <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> est la liste des clusters &slony1; qui sont gérés.</para>
    </listitem>

  </itemizedlist>

  <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> 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> 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> Elle réalise les actions suivantes :</para>

  <itemizedlist>
    <listitem><para> Elle fait un dump du schéma du noeud origine, y compris les informations du schéma 
      du cluster &slony1;. </para>
      <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> Ces informations sont chargées dans une table temporaire fraîchement 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 effectuer 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>
<sect2><title> slony-cluster-analysis </title>

  <indexterm><primary>script - slony-cluster-analysis</primary></indexterm>

  <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> 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>, et ainsi de suite) pour se connecter à un membre du cluster
  &slony1;, et passer le nom du cluster comme argument.</para>

  <para> Le script effectue alors les actions suivantes :</para>
  <itemizedlist>
    <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> Il existe une exemple de script <quote>d'encapsulation</quote>,
  <filename>slony-cluster-analysis-mass.sh</filename>, qui permet de
  pointer vers un ensemble de clusters &slony1;.</para>

  <para> Ceci devrait simplifier la taches des administrateurs ("DBA") sur deux plans : </para>

  <itemizedlist>

    <listitem><para> La documentation de l'état courant du systÚme.</para>
    </listitem>

    <listitem><para> La surveillance des changements de configuration. </para></listitem>
  </itemizedlist>

</sect2>

<sect2 id="configurereplication"> <title> Génération de scripts slonik avec
  <filename>configure-replication.sh</filename> </title>

  <indexterm><primary> générer des scripts slonik pour un cluster </primary></indexterm>

  <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> 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>Valeurs Globales</title>

    <para> Certaines valeurs sont utilisées universellement partout sur le cluster : </para>

    <variablelist>
    <varlistentry><term><envar>  CLUSTER </envar></term>
    <listitem><para> Le nom du cluster Slony-I </para></listitem></varlistentry>
    <varlistentry><term><envar>  NUMNODES </envar></term>
    <listitem><para> Le nombre de noeuds à configurer</para></listitem></varlistentry>

    <varlistentry><term><envar>  PGUSER </envar></term>
    <listitem><para> Le nom du super-utilisateur qui contrÎle la réplication</para></listitem></varlistentry>
    <varlistentry><term><envar>  PGPORT </envar></term>
    <listitem><para> Le numéro du port par défaut</para></listitem></varlistentry>
    <varlistentry><term><envar>  PGDATABASE </envar></term>
    <listitem><para> Le nom de la base de données par défaut</para></listitem></varlistentry>

    <varlistentry><term><envar>  TABLES </envar></term>
    <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> 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>Des valeurs par défauts 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>Valeur spécifique à un noeud</title>

    <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> La base de données à laquelle les scripts doivent se connecter</para></listitem>
      </varlistentry>
      <varlistentry><term><envar>  USER1 </envar></term>
        <listitem><para> Le super-utilisateur utilisé pour la connexion</para></listitem>
        </varlistentry>
      <varlistentry><term><envar>  PORT1 </envar></term>
        <listitem><para> Le port</para></listitem>
      </varlistentry>
      <varlistentry><term><envar>  HOST1 </envar></term>
        <listitem><para> L'hÃŽte</para></listitem>
      </varlistentry>
    </variablelist>

    <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> 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>Les scripts slonik générés</title>
    <para> Les scripts de configuration slonik sont générés dans un répertoire
    temporaire à l'intérieur de <filename>/tmp</filename>.  
    Leur usage est le suivant :</para>

    <itemizedlist>

      <listitem> <para><filename>preamble.slonik</filename> est un fichier
        <quote>préambule</quote> contenant les informations de connexion utilisées
        par les autres scripts.</para>

        <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>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>Vous pouvez/devez lancer les processus slon juste aprÚs cette étape.</para>
      </listitem>
      <listitem><para><filename>  store_paths.slonik</filename></para>

        <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> 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> 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>Il y a deux suppositions dans ce scripts qui peuvent ne pas être
        valides dans certaines circonstances:</para>
      
        <itemizedlist>
          <listitem>
            <para> que toutes les tables et les séquences soit répliquées.</para>
            <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> que toutes les tables sont définies avec des clefs primaires.</para>
            <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'accommoder.
            </para>
          </listitem>
        </itemizedlist>
      </listitem>    
      <listitem>
        <para> <filename> subscribe_set_2.slonik </filename></para>

        <para> et 3,  4,  5, si vous configurez d'autres noeuds... </para>
        
        <para> Ceci est l'étape qui <quote>déclenche</quote>
        réplication.</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> Les processus slon doivent fonctionner au moment ou vous réaliser cette
        étape. Il est absurde 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> profiles dans le style d'Apache pour FreeBSD <filename>ports/databases/slony/*</filename> </subtitle>

  <indexterm><primary> profiles dans le style d'Apache pour FreeBSD </primary> <secondary>FreeBSD </secondary> </indexterm>

  <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> 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> Ce script attend les paramÚtres suivants : </para>
  <itemizedlist>
    <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> 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>, 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> 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> 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> 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> Un script &lslonik; qui configure le nouveau noeud.</para> 
    </listitem>
    <listitem>
      <para> <filename> step2-storepath.slonik </filename> </para> 
      <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> Un script &lslonik; qui demande la souscriptions à tous les ensembles de
      réplications.</para>
    </listitem>
  </itemizedlist>
  <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> 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>