root/traduc/trunk/slony/slon.xml

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

<refentry id="slon">
  <refmeta>
    <refentrytitle id="app-slon-title"><application>slon</application></refentrytitle>
    <manvolnum>1</manvolnum>
    <refmiscinfo>Application</refmiscinfo>
  </refmeta>
  <refnamediv>
    <refname><application>slon</application></refname>
    <refpurpose>
      Le démon &slony1;
    </refpurpose>
  </refnamediv>
 
  <indexterm zone="slon">
    <primary>slon</primary>
  </indexterm>
 
  <refsynopsisdiv>
    <cmdsynopsis>
      <command>slon</command>
      <arg rep="repeat"><replaceable class="parameter">option</replaceable></arg>
      <arg><replaceable class="parameter">clustername</replaceable></arg>
      <arg><replaceable class="parameter">conninfo</replaceable></arg>
    </cmdsynopsis>
  </refsynopsisdiv>
 
  <refsect1>
    <title>Description</title>
    <para><application>slon</application> est un démon applicatif qui 
      <quote>contrÎle</quote> la réplication &slony1;. Une
      instance <application>slon</application> doit être lancée pour
      chaque noeud du cluster &slony1;.</para>
  </refsect1>
  
  <refsect1 id="r1-app-slon-3">
    <title>Options</title>
    <variablelist>
      <varlistentry>
        <term><option>-d</option><replaceable class="parameter"> log_level</replaceable></term>
        <listitem>
          <para>Le paramÚtre <envar>log_level</envar> spécifie quel niveau de messages de debug
          <application>slon</application> doit afficher dans son journal d'activité.</para>
          <para id="nineloglevels">Il y a neuf niveaux de log :
            <itemizedlist>
              <listitem><para>Fatal</para></listitem>
              <listitem><para>Error</para></listitem>
              <listitem><para>Warn</para></listitem>
              <listitem><para>Config</para></listitem>
              <listitem><para>Info</para></listitem>
              <listitem><para>Debug1</para></listitem>
              <listitem><para>Debug2</para></listitem>
              <listitem><para>Debug3</para></listitem>
              <listitem><para>Debug4</para></listitem>
            </itemizedlist>
          </para>
          <para> Les cinq premiers niveau de log ( de Fatal à 
          Info) sont <emphasis>toujours</emphasis> affichés dans les logs.
          Dans les premiÚres versions de &slony1;, le niveau de log 
          <quote>suggéré</quote> était 2, ce qui affichait tous les messages
          jusqu'au niveau Debug2.  Avec &slony1; version 2, il est 
          recommandé de positionner <envar>log_level</envar> à 0; la 
          pluspart des informations intéressantes sont produites à 
          des niveaux supérieurs à celui-là .</para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-s</option><replaceable class="parameter"> Interval entre les vérifications SYNC</replaceable></term>
        <listitem>
          <para>Le paramÚtre <envar>sync_interval</envar>, exprimé en millisecondes,
          indique à quelle fréquence <application>slon</application> doit 
          vérifier si un événement <command>SYNC</command> doit 
          être produit. La valeur par défaut est 2000 ms.  La boucle principale
          dans <function>sync_Thread_main()</function> est endormie pendant 
          des intervalles de <envar>sync_interval</envar> millisecondes 
          entre chaque itérations.</para>
       
          <para>Un intervalle de vérifications trÚs court garantit que le noeud
          origine soit <quote>trÚs suivi</quote>, car il met à jour les abonnés
          plus fréquemment. Si vous avez des séquences répliquées qui sont 
          souvent mises à jour <emphasis>sans</emphasis> que certaines tables
          ne soient affectées, cela évite que des opérations qui mettent 
          à jour uniquement ces séquences soient effectuées, et ainsi 
          évite la génération d'événements de synchronisations.</para>

          <para>Si un noeud n'est pas l'origine d'un set de réplication, et donc qu'il
          ne reçoit aucune mise à jour des données répliquées, alors il est 
          un peu inutile de mettre une valeur inférieure à celle du paramÚtre 
          <envar>sync_interval_timeout</envar>.</para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-t</option><replaceable class="parameter">intervalle maximal entre deux SYNC</replaceable></term>
        <listitem>
          <para>A la fin de chaque période  <envar>sync_interval_timeout</envar>
          , un événement <command>SYNC</command> est produit sur le noeud 
          <quote>local</quote> même si il n'y eu aucune mise à jour des 
          données répliquées et qu'aucun <command>SYNC</command> n'a été 
          généré. </para>

          <para> Si l'activité de l'application s'arrête, soit parce que
          l'application a été éteinte, soit parce que les utilisateurs humains
          sont rentrés chez eux et arrêtés les mises à jour, alors le
          démon  &lslon; continue de tourner et se réveille toutes les 
          <envar>sync_interval</envar> millisecondes, et si aucune mise
          à jour ne s'est produite, alors aucun événement  <command>SYNC</command>
          n'est généré. Sans ce paramÚtre <quote>timeout</quote>,
          <emphasis>aucun</emphasis> événement <command>SYNC</command> 
          ne pourrait être produit, et cela entraînerait le chute du 
          systÚme de réplication. </para>

          <para> Le paramÚtre <envar>sync_interval_timeout</envar> provoque
          la génération de <command>SYNC</command>, même si il n'y a pas 
          réellement de travail de réplication a faire. Plus la valeur de 
          cette paramÚtre est basse, plus les évÚnements  <command>SYNC</command>
          lorsque l'application n'est pas active. Ceci a deux 2 effets :</para>
          <itemizedlist>
            <listitem>
              <para> Le systÚme aura plus de travail.</para> 
              <para> ( Cependant puisque l'application n'utilise pas 
                    la base de données et qu'il n'y a pas de données à répliquer,
                    la charge de travail supplémentaire sera assez simple à gérer.)</para>
            </listitem>
            <listitem>
              <para> La réplication sera tenue un peu plus <quote>à jour</quote>.</para>
              <para> ( Cependant puisqu'il n'y a pas de données à répliquer, être
              plus souvent <quote>mis à jour</quote> est un mirage.) </para>
            </listitem>
          </itemizedlist>
          <para>La valeur par défaut est 10000 ms et la valeur maximale est 120000 ms. 
          Par défaut, vous pouvez prévoir que chaque noeud soit  
          <quote>synchronisé</quote> par un <command>SYNC</command> toutes les 10 secondes.</para>
          <para>Notez que des événements <command>SYNC</command> sont aussi générés 
          sur chaque noeud abonné. Cependant puisqu'ils ne contiennent 
          de données à répliquer par les autres noeuds, les évÚnements 
          <command>SYNC</command> des noeuds abonnés ne sont pas terriblement intéressant.</para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-g</option><replaceable class="parameter"> taille du groupe</replaceable></term>
        <listitem>
          <para>L'option <envar>sync_group_maxsize</envar> contrÃŽle la taille maximumale d'un groupe <command>SYNC</command>,
          . La valeur par défaut est 6.  Ainsi, si un noeud particulier a 
          200 événements <command>SYNC</command>s de retard, il essaiera de les regrouper 
          par groupes dont la taille maximale sera <envar>sync_group_maxsize</envar>.
          Ceci doit permettre de réduire le temps de lantence au démarrage (NdT : "overhead")
          en réduisant le nombre de transactions à <quote>comitter</quote>.</para>
          <para>La valeur par défaut est 6 est probablement adéquate pour les petits systÚmes
          qui ne peuvent allouer que des quantités limitées de mémoire à 
          <application>slon</application>.  Si vous avez beaucoup de mémoire
          il est raisonnable d'augmenter cette valeur, car cela augmentera 
          la quantité de travail réalisée à chaque transaction, et cela
          permettra a un noeud abonné de rattraper plus vite son retard.</para>
          <para>Les processus Slon sont souvent trÚs petits; même en cas
          de valeur trÚs forte pour cette option, <application>slon</application>
          devrait simplement grossir de quelques MB.</para>
          <para>Le gros avantage d'augmenter ce paramÚtre est que 
          cela divise le nombre de transaction
          <command>COMMIT</command>s; passer de 1 to 2 aura probablement
          un impact considérable, mais le bénéfice se réduit progressivement
          lorsque la taille des groupes est suffisamment large.
          Il n'y aura probablement pas de différence notable entre 80 et 90.
          Rendu à ce niveau, l'augmentation de cette
          valeur dépend du fait que les grands ensembles de <command>SYNC</command>s
          perturbent les curseurs de <envar>LOG</envar> en consommant
          de plus en plus de mémoire et nécessitant plus d'efforts lors 
          des tris.</para>
          <para>Dans &slony1; version 1.0, <application>slon</application> essaie
          toujours de regrouper un maximum de <command>SYNC</command>s ensemble
          , ce qui <emphasis>n'est pas</emphasis> idéal si la réplication
          a été déstabilisée par de grosses mises à jour ( <emphasis>par exemple
          </emphasis> : une transaction unique qui met à jour des centaines 
          de milliers de lignes) ou lorsque les <command>SYNC</command>s 
          ont été interrompus sur un noeud origine, ce qui fait 
          que les suivants sont volumineux. Vous rencontrerez
          ce problÚme : en regroupant des <command>SYNC</command>s trÚs
          larges, le processus <application>slon</application> peut échouer.
          Au redémarrage, il essaie a nouveau de traiter ce large ensemble 
          de <command>SYNC</command>s, et il retombe sur le même problÚme
          encore et encore jusqu'Ã  ce qu'un administrateur interrompe tout cela
          et change la valeur de l'option <option>-g</option> pour
          sortir de cette situation d'<quote>inter-blocage</quote>.</para> 
          <para>Au contraire Avec &slony1; version 1.0, le démon <application>slon</application>
          'adapte en augmentant <quote>progressivement</quote> le nombre de 
          <command>SYNC</command> par groupe, de 1 jusqu'Ã  la valeur maximale.
          Ainsi, si quelques <command>SYNC</command>s pausent problÚme, le démon
          <application>slon</application> pourra (avec s'il est surveillé par
          un processus chien de garde) traiter un par un ces évÚnements
          <command>SYNC</command>s problématique, et ainsi éviter l'intervention
          d'un administrateur.</para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-o</option><replaceable class="parameter"> temps de synchronisation souhaité</replaceable></term>
        <listitem>
          <para> La période <quote>maximale</quote> pour un groupe de <command>SYNC</command>s.</para>
          <para> Si la réplication est en retard, le démon slon va progressivement augmenter le
          nombre de <command>SYNC</command>s groupés ensemble, dans le but de 
          ne pas dépasser le temps spécifié par <envar>desired_sync_time</envar>.
          (pour cela, Slon se base sur le temps pris par le 
          <emphasis>dernier</emphasis> group de <command>SYNC</command>s).</para>
          <para> La valeur par défaut est 60000ms, c'est à dire une minute. </para>

          <para> Ainsi vous pouvez prévoir (en tout cas espérer ! )
          que vous aurez un <command>COMMIT</command> environ
          toutes les minutes.</para>

          <para> Cela n'est pas <emphasis>complÚtement</emphasis> prévisible,
          car il est possible de demander une <emphasis>trÚs grosse mise à jour
          </emphasis>,qui fera <quote>exploser</quote> la taille du 
          <command>SYNC</command>. Dans ce cas là , l'heuristique sera 
          rétablie pour le <emphasis>prochain</emphasis> groupe.</para>

          <para> L'effet final est d'améliorer la façon dont 
          <productname>Slony-I</productname> gÚre les variations 
          du trafic.  En commençant avec 1 événement <command>SYNC</command>, puis
          en augmentant progressivement, même si certaines variations seront 
          assez grandes pour provoquer un crash du processus <productname>PostgreSQL</productname>,
          <productname>Slony-I</productname> redémarrera en traitant un seul <command>SYNC</command>
          à la fois, afin que poursuivre le processus de réplication autant que possible.</para>
        </listitem>
      </varlistentry>      
      <varlistentry>
        <term><option>-c</option><replaceable class="parameter"> cycles de nettoyage</replaceable></term>
        <listitem>
          <para>La valeur <envar>vac_frequency</envar> indique la fréquence des opérations
          <command>VACUUM</command> lors des cycles de nettoyage.</para>
          <para>Positionner cette valeur à zéro pour désactiver les nettoyages 
          initiés par <application>slon</application>. Si vous utilisés un 
          mécanisme tel que <application>pg_autovacuum</application> pour
          lancer les vacuums, vous n'aurez probablement pas besoin que
          slon initie des vacuums de lui-même. Sinon, il existe des tables
          utilisées par <productname>Slony-I</productname> qui collectent 
          <emphasis>beaucoup</emphasis> de tuples morts, et qui doivent
          être nettoyées fréquemment, en particulier &pglistener;.</para>
          <para> A partir de &slony1; version 1.1, cela change un peu; le processus
          de nettoyage cherche, d'itération en itération, l'identifiant
          de la plus ancienne transaction encore active dans le systÚme.
          Si l'identifiant ne change pas entre deux itérations, alors 
          il existe une vieille transaction en activité, et donc un
          <command>VACUUM</command> n'apportera rien de bon. A la place, 
          le processus de nettoyage déclenche simplement une opération <command>ANALYZE</command>
          sur ces tables afin de mettre à jours les statistiques dans <envar>pg_statistics</envar>.</para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-p</option><replaceable class="parameter"> fichier du PID </replaceable></term>
        <listitem>
          <para>La variable <envar>pid_file</envar> contient le nom du fichier dans lequel le PID
          (identifiant du processus) du démon <application>slon</application> est stocké.</para>
          <para>Cela simplifie la création de scripts de surveillance des processus 
          <application>slon</application> qui s'exécute sur un hÎte.</para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-f</option><replaceable class="parameter"> fichier de configuration</replaceable></term>
        <listitem>
          <para>Fichier qui contient la configuration <application>slon</application>.</para>
        
          <para> La configuration configuration est  détaillée plus loin dans le chapitre <link 
          linkend="runtime-config">Configuration de Slon</link>. Si 
          vous avez défini un ensemble complexe de paramÚtre, ou si vous ne voulez
          pas que les paramÚtres soient visibles dans les variable d'environnement 
          ( notamment les mots de passe ), il est plus pratique de placer une partie,
          voire l'ensemble des paramÚtres dans un fichier de configuration. 
          Vous pouvez pouvez également placer les paramÚtres communs à tous les
          processus slon dans un fichier de configuration partagé et définir
          en ligne de commande d'autres paramÚtres que les informations de connexions.
          Vous pouvez aussi créer un fichier de configuration pour chaque noeud.</para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-a</option><replaceable class="parameter"> répertoire des archives</replaceable></term>
        <listitem>
          <para>L'option <envar>archive_dir</envar> indique le dossier dans lequel on 
          place la séquence de fichiers archives contenant les événements <command>SYNC</command>
          utilisés en mode &logshiplink;.</para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-x</option><replaceable class="parameter"> commande à appliquer pour l'archivage des journaux</replaceable></term>
        <listitem>
          <para>Le paramÚtre <envar>command_on_logarchive</envar> indique la commande qui doit
          être exécutée à chaque fois qu'un fichier SYNC est correctement généré.</para>
          <para> Voir le chapitre <xref linkend="slon-config-command-on-logarchive"/> pour plus de détails.</para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-q</option><replaceable class="parameter"> quitter en fonction d'un fournisseur </replaceable></term>
        <listitem>
          <para>L'option <envar>quit_sync_provider</envar> indique quel processus fournisseur 
          doit être surveiller afin d'arrêter la réplication aprÚs un événement donné.
          Ceci doit être utilisé conjointement avec l'option 
          <option>-r</option> ci-dessous...</para>

          <para> Cela permet de stopper la réplication sur un processus <application>slon</application>
          aprÚs un certain point. </para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-r</option><replaceable class="parameter"> quitte aprÚs un numéro d'événement </replaceable></term>
        <listitem>
          <para>Le paramÚtre <envar>quit_sync_finalsync</envar> indique le numéro de l'événement
          aprÚs lequel un processus de réplication doit se terminer.  
          Ceci doit être utilisé conjointement avec l'option 
          <option>-q</option> ci-dessus...</para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-l</option><replaceable class="parameter">  interval de retard </replaceable></term>
        <listitem>
          <para>L'option <envar>lag_interval</envar> spécifie une valeur temporelle 
          ( en anglais ) telle que <command> 3 minutes </command>, <command> 4 hours </command>
          ou <command> 2 days </command> qui indique que le temps de retard qu'un noeud doit avoir
          par rapport à son fournisseur. Cela implique que les événements seront
          ignorés tant que leur age sera inférieur à cet intervalle.</para>

          <warning><para> Il y a un effet secondaire à ce retard;
          Les événements qui demande que tous les noeuds se synchronisent, 
          notamment ceux qui sont produits lors d'une opération <xref linkend="stmtfailover"/> 
          et d'un <xref linkend="stmtmoveset"/>, devront attendre pendant cet interval
          de temps.</para>

          <para> C'est un comportement qui n'est pas idéal dans le cas d'une bascule
          aprÚs une panne, ou lorsque l'on veut exécuter des scripts DDL ( <xref
          linkend="stmtddlscript"/> ). </para>
          </warning>
        </listitem>
      </varlistentry>
    </variablelist>
  </refsect1>
  <refsect1>
    <title>Valeur de retour ( "Exit Status" ) </title>
    <para><application>slon</application> renvoie 0 dans le shell si il s'est terminé
    normalement. En cas d'erreur fatale, il exécute la fonction <function>exit(-1)</function>
    ( qui envoie en général un valeur de retour de 127 ou 255, suivant votre systÚme d'exploitation ).</para>
  </refsect1>
</refentry>