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 n&oelig;ud 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 le niveau de
	    messages de débogage que <application>slon</application> doit
	    afficher dans son journal d'activité.
	  </para>
	  
          <para id="nineloglevels">Il y a neuf niveaux de débogage&nbsp;:
            <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 niveaux de débogage (de Fatal à Info) sont
	    <emphasis>toujours</emphasis> affichés dans les traces. Dans les
	    précédentes versions de &slony1;, la valeur <quote>suggérée</quote>
            pour <envar>log_level</envar> était 2, qui fournit toutes les traces
	    jusqu'au niveau de débogage 2.  Dans &slony1; version 2, il est
	    recommandé de configurer <envar>log_level</envar> à 0&nbsp;; la
	    plupart des informations intéressantes dans les traces est générée
	    à des niveaux supérieurs.
	  </para>
        </listitem>
      </varlistentry>
      
      <varlistentry>
        <term><option>-s</option> <replaceable class="parameter">Intervalle 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ération.
	  </para>
       
          <para>
	    Un intervalle de vérifications très court garantit que le n&oelig;ud
            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 synchronisation.
	  </para>

          <para>
	    Si un n&oelig;ud n'est pas l'origine d'un ensemble 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>
	    À la fin de chaque période <envar>sync_interval_timeout</envar>,
            un événement <command>SYNC</command> est produit sur le n&oelig;ud
            <quote>local</quote> même s'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 la 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 s'il n'y a pas
            réellement de travail de réplication a faire. Plus la valeur de
            ce paramètre est bas, plus les évènements <command>SYNC</command>
            lorsque l'application n'est pas active. Ceci a deux effets&nbsp;:
	  </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 n&oelig;ud soit
            <quote>synchronisé</quote> par un <command>SYNC</command> toutes les
	    dix secondes.
	  </para>
	  
          <para>
	    Notez que des événements <command>SYNC</command> sont aussi générés
            sur chaque n&oelig;ud abonné. Cependant, puisqu'ils ne contiennent
	    pas de données à répliquer par les autres n&oelig;uds, les évènements
            <command>SYNC</command> des n&oelig;uds abonnés ne sont pas
	    terriblement intéressants.</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
	    maximale d'un groupe <command>SYNC</command>. La valeur par défaut
	    est 6. Ainsi, si un n&oelig;ud particulier a 200 événements
	    <command>SYNC</command> 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&nbsp;: «&nbsp;overhead&nbsp;»)
            en réduisant le nombre de transactions à <quote>valider</quote>.
	  </para>
	  
          <para>
	    La valeur par défaut, 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 à un n&oelig;ud abonné de rattraper plus vite son
	    retard.
	  </para>
	  
          <para>
	    Les processus Slon sont souvent très petits&nbsp;; même en cas
            de valeurs très fortes pour cette option,
	    <application>slon</application> devrait simplement grossir de
	    quelques Mo.
	  </para>
	  
          <para>
	    Le gros avantage d'augmenter ce paramètre est que cela divise
	    le nombre de transactions <command>COMMIT</command>&nbsp;; passer
	    de 1 à 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>
            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> 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> ont été interrompus sur un n&oelig;ud origine,
	    ce qui fait que les suivants sont volumineux. Vous rencontrerez ce
	    problème&nbsp;: en regroupant des <command>SYNC</command> très
            larges, le processus <application>slon</application> peut échouer.
            Au redémarrage, il essaie à nouveau de traiter ce large ensemble
            de <command>SYNC</command> 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; 1.1 et les versions ultérieures, le démon
	    <application>slon</application> s'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> posent problème, le démon
	    <application>slon</application> pourra (s'il est surveillé par
            un processus chien de garde) traiter un par un ces évènements
            <command>SYNC</command> problématiques, 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>.
	  </para>
	  
          <para>
	    Si la réplication est en retard, le démon slon va progressivement
	    augmenter le nombre de <command>SYNC</command> 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> groupe de
	    <command>SYNC</command>).
	  </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&nbsp;!) 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 un é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>
	    Positionnez cette valeur à zéro pour désactiver les nettoyages
	    initiés par <application>slon</application>. Si vous utilisez un
            mécanisme tel que <application>pg_autovacuum</application> pour
            lancer les VACUUM, vous n'aurez probablement pas besoin que slon
	    initie des VACUUM de lui-même. Sinon, il existe des tables
	    utilisées par <productname>Slony-I</productname> qui collectent
            <emphasis>beaucoup</emphasis> de lignes mortes et qui doivent
            être nettoyées fréquemment, en particulier &pglistener;.
	  </para>
	  
          <para>
	    À partir de &slony1; version 1.1, cela change un peu&nbsp;; 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. À 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écutent 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 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 variables 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 é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 n&oelig;ud.
	  </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 surveilleé 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 le temps
	    de retard que doit avoir un n&oelig;ud par rapport à son fournisseur.
	    Cela implique que les événements seront ignorés tant que leur âge
	    sera inférieur à cet intervalle.
	  </para>

          <warning>
	    <para>
	      Il y a un effet secondaire à ce retard&nbsp;; Les événements qui
	      demandent que tous les n&oelig;uds 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</title>
    
    <para>
      <application>slon</application> renvoie 0 dans le shell s'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 une valeur de retour
      de 127 ou 255, suivant votre système d'exploitation).
    </para>
  </refsect1>
</refentry>