root/traduc/trunk/slony/bestpractices.xml

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

<sect1 id="bestpractices">
  <title> &slony1; <quote>Bonnes Pratiques</quote> </title>
  <indexterm><primary>bonnes pratiques pour utiliser &slony1;</primary></indexterm>
  <para> Il est courant pour les administrateurs de vouloir exploiter des systÚmes 
  en utilisant un ensemble de <quote>bonnes pratiques</quote> disponibles et documentées.
  Documenter ce genre de choses est essentiel pour l'ISO 9000, l'ISO 9001, 
  et d'autres type de certifications d'organisation. </para>

  <para> Il est intéressant d'introduire toute discussion sur des <quote>bonnes
  pratiques</quote> en mentionnant que chaque organisation utilisant &slony1; est unique,
  et qu'il est nécessaire qu'une politique locale reflÚte les caractéristiques administratives locales.
  C'est pour cette raison que &slony1; n'impose <emphasis>as</emphasis> ses propres rÚgles pour des 
  choses telles que <link linkend="failover">les bascules d'urgence</link>; elles devront être déterminées
  en fonction de l'architecture globale de votre réseau, de votre ensemble de serveurs de base de données, 
  et de votre maniÚre d'utiliser ces serveurs.</para>

  <para> Il y a toutefois, un certain nombre de choses que les pionniers de &slony1; ont
  découvertes qui peuvent au moins aider à concevoir le genre de rÚgles d'administration
  que vous pourriez mettre en place. </para>
  <itemizedlist>
    <listitem>
      <para> &slony1; est systÚme multi-clients et multi-serveurs complexe,
      ce qui implique qu'il existe un ensemble presque infini d'endroits 
      où des problÚmes peuvent surgir.</para> 

      <para> c'est donc naturellement que la maintenance d'un environnement propre, cohérent
      est réellement décisif, car tout type de <quote>cafouillage</quote> dans l'environnement
      peut provoquer des problÚmes ou masquer le problÚme réel. </para>

      <para> De nombreux utilisateurs ont rapportés des problÚmes provenants d'incompatibilités
      entre les versions de &slony1;, les librairies locales, et les librairies de &postgres;.
      Chaque détail compte : vous devez identifier clairement sur quels hÎtes sont hébergées 
      quelles versions de quels logiciels. </para>

      <para> Normalement il s'agit juste d'être discipliné lors du déploiement de vos logiciels, et 
      ce défi est une conséquence naturelle lorsqu'on met en place un systÚme distribué constitué
      par un grand nombre de composants qui doivent correspondre.</para>
    </listitem>

    <listitem>
      <para> Si un script slonik ne fonctionne pas comme prévu à la premiÚre 
      tentative, il serait téméraire de tenter de l'exécuter à nouveau tant que le 
      problÚme n'a pas été trouvé et résolu.  </para>

      <para> Il y a trÚs peu de commandes slonik tel que <xref
      linkend="stmtstorepath"/> qui se comporte de maniÚre déterministe;
      si vous exécuter <xref linkend="stmtstorepath"/> plusieurs fois,
      cela mettra plusieurs fois la même valeur dans la table
      <envar>sl_path</envar>.  </para>

      <para> Au contraire <xref linkend="stmtsubscribeset"/> se comporte de 
      deux maniÚres <emphasis>trÚs</emphasis> différentes selon si 
      l'abonnement a déjà été activé ou pas; si l'initialisation de 
      l'abonnement n'a pas fonctionné à la toute premiÚre tentative, 
      soumettre à nouveau cette requête n'arrangera <emphasis>pas</emphasis>
      la situation. </para>
    </listitem>

    <listitem>
      <para> Principe: Utilisez un zone de temps ("timezone") stable et non-ambigÃŒe 
      tel que UTC ou GMT.</para>

      <para> Les utilisateurs ont rencontrés des problÚmes pour faire fonctionner
      &lslon; correctement lorsque leur systÚme utilisait une zone de temps que 
      &postgres; ne pouvait pas reconnaître tel que CUT0 ou WST. Il est nécessaire
      que vous utilisiez une zone de temps que &postgres; reconnaît correctement.
      De plus, il est préférable d'utiliser une zone qui n'est pas soumise au 
      basculement entre heure d'été et heure d'hivers.</para>

      <para> Le choix <quote>géographiquement neutre</quote> semble être
      <command><envar>TZ</envar>=UTC</command> ou
      <command><envar>TZ</envar>=GMT</command>, par ailleurs Assurez-vous que 
      vos serveurs sont <quote>synchronisés</quote> grâce à l'utilisation 
      de NTP sur l'ensemble de votre environnement. </para>

      <para> Voir aussi <xref linkend="times"/>.</para>
    </listitem>

    <listitem>
      <para> Principe: Les transactions longues c'est mal </para>

      <para> La FAQ a un chapitre sur la <link linkend="pglistenerfull">croissance de
      &pglistener; </link> qui explique tout cela en détails; pour simplifier :
      les transactions longues ont de nombreux effets secondaires. Elles sont problématiques
      en particulier sur un noeud <quote>origine</quote>, s'accaparant les verrous, rendant inefficace 
      les vacuums , et ainsi de suite.</para>

      <para> Dans la version 1.2, certains comportement <quote>désagréables</quote> devraient
      être diminués car :</para>

      <itemizedlist>
        <listitem>
          <para> Les événements dans &pglistener; sont seulement générés lorsque
          les mise à jours de réplication sont relativement rare, ce qui devrait 
          impliquer que les systÚmes chargés ne vont pas générer beaucoup de tuples morts
          dans cette table.</para>
        </listitem>

        <listitem>
          <para> Le systÚme va périodiquement faire une rotation (en utilisant 
          <command>TRUNCATE</command> pour nettoyer l'ancienne table) entre les deux tables de logs,
          <xref linkend="table.sl-log-1"/> et <xref linkend="table.sl-log-2"/>, évitant une croissance illimitée de l'espace <quote>mort</quote> à cet endroit.  </para>
        </listitem>
      </itemizedlist>
    </listitem>
    <listitem>
      <para>Les rÚgles de  <link linkend="failover"> Bascule en urgence </link> 
      devraient être planifiées à l'avance.  </para>

      <para> Cela peut simplement se résumer à réfléchir à une liste
      de priorité indiquant ce qui devrait basculer vers quoi, plutÎt 
      que d'essayer d'automatiser la bascule. Quoiqu'il en soit savoir
      au préalable ce qu'il faut faire réduit le nombre d'erreurs commises.</para>

      <para> Chez Afilias, une grande variété de guide interne, tel que <citation>Le guide 
      de l'administrateur réveillé à 3 heures du matin..</citation>, ont été
      rédigé pour fournir les procédures à suivre en cas d'événements <quote>malheureux</quote>.
      Ce genre de matériel est hautement spécifique à l'environnement  et à l'ensemble d'applications
      présentes, donc vous devriez rédiger vos propres documents. Ceci est un des composants vitaux de 
      tout procédure de reprise aprÚs crash.</para>
    </listitem>

    <listitem>
      <para> <xref linkend="stmtmoveset"/> doit être utliséￜ pour
      la maintenance préventive afin d'éviter l'apparition des
      problÚmes nécessitant une <link linkend="failover">
      bascule aprÚs panne ("failover") </link>. </para>
    </listitem>

    <listitem> 
      <para> La politique de <command>VACUUM</command> doit être 
      définie avec soin.</para>

      <para> Comme indiqué précédemment, <quote>les transactions longues sont maléfiques.</quote> 
      La commande <command>VACUUM</command> n'est pas une exception à cette rÚgle.
      Un <command>VACUUM</command> sur une grande table ouvrira une transaction longue
      qui aura tous les effets négatifs déjà cités.</para>
    </listitem>

    <listitem>
      <para> Si vous utiliser le processus autovacuum process avec une
      version récente de &postgres;, vous pouvez éviter de le faire pour les tables &slony1; 
      car &slony1; est un peu plus intelligent que le démon autovaccuum lorsqu'il s'agit de 
      vacuum dans des conditions de réplication ( <emphasis>par exemple</emphasis> : la purge
      des anciennes données ).</para>

      <para> Reportez-vous au chapitre <xref linkend="maintenance-autovac"/> pour plus de 
      détails. </para>
    </listitem>


    <listitem>
      <para> Il a été prouvé qu'il est préférable d'exécuter tous les démons &lslon; 
      sur un serveur central pour chaque sous-réseau. </para>

      <para> Chaque &lslon; doit être hébergé par hÎte sur le même réseau local que 
      le noeud qu'il opÚre, car il envoie <emphasis>beaucoup</emphasis> de 
      communications avec sa base de donnée et que la connexion doit être aussi fiable 
      que possible.</para>

      <para> En théorie, les <quote>meilleures</quote> performances sont prévues lorsque
      le &lslon; fonctionne sur le même serveur que la base qu'il opÚre. </para>

      <para> En pratique, déployer les processus &lslon; processes et leur configuration
      à travers un réseau d'une douzaine de serveurs se révÚle être difficilement gérable.</para>
    </listitem>

    <listitem>
      <para>Les processus &lslon; doivent évoluer dans le même
      <quote>contexte réseau</quote> que le noeud qu'il opÚre, afin que la 
      liaison entre eux soir une connexion <quote>locale</quote>.  
      N'établissez <emphasis>pas</emphasis> ce genre de liaison à 
      travers un réseau WAN. </para>

      <para> Une coupure de lien WAN  peut provoquer des connexions
      <quote>zombies</quote>, et le comportement typique du TCP/IP consiste à 
      <link linkend="multipleslonconnections"> laisser ces connexions persister,
      empêchant le démon slon de redémarrer pendant environ deux heures. </link></para>

      <para> Il n'est pas difficile de remédier à cela; Vous devez simplement tuer les
      processus liés aux connexions persistantes avec la commande <command>kill
      SIGINT</command>. Cependant en exécutant  les &lslon; localement, vous êtes
      généralement à l'abri de ce genre de problÚmes. </para>
    </listitem>

    <listitem>
      <para> Si vous rencontrez ce genre de problÚmes, avant de vous exciter,
      essayez de tuer et redémarrer tous les processus &lslon;. 
      Historiquement, cette méthode a souvent résolu ce genre de 
      <quote>petit tracas.</quote>.</para>

      <para>A quelques rares exceptions, il n'est pas trÚs grave de tuer et relancer les 
      processus &lslon;. Chaque &lslon; se connecte à la base de données qu'il gÚre, puis 
      ouvre les connexions nécessaires à la propagation des événements.
      Si vous tuer un &lslon;, vous provoquez simplement l'interruption de ces connexions.
      Si un évÚnement <command>SYNC</command> ou un autre événement est en cours de propagation,
      il n'y a pas de problÚme : la transaction sera annulée ("roll back") et lorsque le &lslon; 
      sera relancé, l'évÚnement sera retraiter à partir de zéro.</para>

      <para> L'exception qui rend un redémarrage de &lslon; indésirable est le cas
      où une commande <command>COPY_SET</command> est en cours d'exécution sur un
      grand ensemble de réplication. Dans ce genre de cas, arrêter un &lslon; peut
      annuler plusieurs heures de travail. </para>

      <para> Dans les premiÚres versions de &slony1;, il était fréquent que 
      des connexions soient un peu <quote>dérangée</quote>, ce qu'on pouvait
      réparer en redémarrant &lslon;.  Ceci est devenu nettement plus rare,
      mais il est parfois utile de redémarrer &lslon;.  En cas de  
      <quote>panne réseau</quote>, cela peut résoudre le problÚme des
      connexions à la base défuntes.</para>
    </listitem>

    <listitem>
      <para>La section sur les <link linkend="ddlchanges">changements de modÚle de données</link>
      détaille quelques bonnes pratiques qui sont utiles lorsque l'on souhaite modifier le
      schémas de la base de données. </para>
    </listitem>

    <listitem>
      <para> Gestion des clefs primaires </para> 

      <para> Comme précisé dans la section <link linkend="definingsets">
      Ensembles de réplication</link>, il est <emphasis>idéal</emphasis> que 
      chaque table répliquée dispose d'un vraie contrainte de clef primaire;
      il est <emphasis>acceptable</emphasis> d'utiliser une <quote>clef primaire 
      candidate.</quote></para>

      <para> Il n'est <emphasis>pas recommandé</emphasis> d'utiliser une clef définie 
      par &slony1; (crée par <xref linkend="stmttableaddkey"/>) pour
      proposer une clef primaire candidate, car cela introduit la possibilité
      d'échecs de certaines mises à jour sur la table à cause de l'index unique de cette
      clef. Ceci entraînerait potentiellement des bugs dans votre application à cause 
      de &slony1;.</para>


      <warning><para> Dans la version 2 de &slony1;, <xref
      linkend="stmttableaddkey"/> n'est plus supportée. Vous <emphasis>devez</emphasis> absolument
      avoir soit une vraie clef primaire, soit une clef primaire candidate.</para></warning>
    </listitem>

    <listitem>
      <para> La section <link linkend="definesets"> Définir les ensembles de réplication
      </link> vous suggÚre des stratégies pour déterminer comment regrouper les tables 
      et les séquences en ensembles de réplication. </para>
    </listitem>

    <listitem>
      <para> Il est évident que les actions qui peuvent supprimer beaucoup 
      de données doivent être effectuées avec le plus grand soin; La section 
      <link linkend="dropthings">Supprimer des éléments de la réplication</link>
      évoque les différentes sortes de <quote>suppression</quote> que &slony1; supporte.  </para>
    </listitem>

    <listitem>
      <para> <link linkend="locking">ProblÚmes d'inter-blocages</link></para>

      <para> Certaines opérations &slony1;, notament <link linkend="stmtsetaddtable"> <command>set add table</command> </link>,
      <link linkend="stmtmoveset"> <command> move set</command> </link>,
      <link linkend="stmtlockset"> <command> lock set </command> </link>,
      et <link linkend="stmtddlscript"> <command>execute script</command>
      </link> nécessite l'acquisition de <emphasis>verrous exclusifs</emphasis> sur les tables répliquées.</para>

      <para> En fonction de type d'activité de votre base de données, cela
      peut ( ou pas ) provoquer des coupures de services ( heureusement assez brÚves ). </para>
    </listitem>

    <listitem>
      <para> Que faire des ordres DDL ? </para>

      <para> &slony1; fonctionne en détectant les mises à jour sur les tables
      grâce à des triggers qui sont placés sur ces tables.
      Cela implique que les mises à jours que sont font au moyen de
      méthodes qui ne déclenche pas les triggers ne seront pas propagées.
      Les commandes <command>ALTER TABLE</command>, <command>CREATE OR
      REPLACE FUNCTION</command>, <command>CREATE TABLE</command>, sont toutes 
      des requêtes SQL que &slony1; ne peut pas détecter. </para>
      
      <para> Pour ce genre de situation, la philosophie de &slony1;
      consiste à considérer que les développeurs compétents n'écrivent
      jamais de code auto-modifiant et en particulier du code modifiant 
      les modÚles de données à la volée. &slony1; ne cherche pas à faciliter 
      ce genre de modification du schémas de données. </para>
      
      <para> Cependant il existe des cas où cela est nécessaire, ainsi la <link
      linkend="stmtddlscript"> <command>execute script</command> est fournie
      pour appliquer des changements DDL au même point dans 
      le flux de transactions sur tous les serveurs.</link> </para>
      
      <para> Malheureusement, cela provoque de nombreux verrous sur 
      les objets de la base de données. Modifier les tables nécessite 
      de l'acquisition d'un verrou exclusif sur ces objets; ainsi le 
      <command>script d'exécution des modification</command> entraîne
      un verrous exclusif sur <emphasis>toutes</emphasis> les tables
      répliquées. Cela peut s'avérer trÚs problématiques lorsque les 
      applications fonctionnent; des inter-blocages ("deadlocks") peuvent
      alors se produire.</para>

      <para> Une position particuliÚrement dogmatique défendue par certains
      consiste à dire qu'il faut <emphasis>toujours</emphasis> propager
      les changements de modÚles de données avec un <command>script d'exécution</command>.
      Cela garantit que les noeuds restent consistants, cependant le coût des verrous
      et des inter-blocages est trop élevé pour certains utilisateurs.</para>

      <para> Chez Afilias, notre approche est moins dogmatique; il y a 
      <emphasis>certains</emphasis> changements qui 
      <emphasis>doivent</emphasis> être appliquées avec un <command>script d'exécution</command>, 
      mais nous appliquons certaines modification de maniÚre indépendante.</para>
    
      <itemizedlist>
        <listitem>
          <para> Liste de changements qui doivent être effectuée dans un <command>script d'exécution</command> :</para>
          <itemizedlist>
            <listitem>
              <para> Toutes les commandes <command>ALTER TABLE</command></para>
            </listitem>
          </itemizedlist>
        </listitem>
        <listitem>
          <para> Listes des changement qui ne nécessitent pas un <command>script d'exécution :</command> </para>  
          <itemizedlist>
            <listitem>
              <para> <command>CREATE INDEX</command> </para>
            </listitem>
            <listitem>
              <para> <command>CREATE TABLE</command> </para>
              <para> Les tables qui ne sont pas répliquées n'ont pas besoin de ces mécanismes.</para>
            </listitem>
            <listitem>
              <para> <command>CREATE OR REPLACE FUNCTION </command> </para>
              <para> Typiquement, le chargement de nouvelles version de fonctions 
              peut être effectuée sans que &slony1; en soit <quote>averti</quote>.
              A l'exception évidente des cas où la nouvelle fonction est déployée suite 
              à la modification d'une table. Dans ce cas là , la nouvelle version
              doit être déployé de maniÚre synchronisée avec le 
              <command>script d'exécution</command> qui modifie la table.</para>

              <para> De la même maniÚre, les ordres <command>CREATE TYPE</command>, <command> CREATE
              AGGREGATE </command>,  etc. n'ont pas besoin d'être forcément insérés de
              maniÚre <quote>parfaitement synchronisés</quote> sur l'ensemble des noeuds.</para>
            </listitem>
            <listitem>
              <para> Les ordres de gestion des autorisations, tels que <command> CREATE USER
              </command>, <command> CREATE ROLE </command>, <command>GRANT
              </command>, etc. sont inutile pour &slony1; car il est exécuté avec les droits 
              de <quote>super-utilisateur</quote>. </para>

              <para>Dans la pratique, il est utile d'avoir différentes politiques de sécurité
              sur les noeuds. L'accÚs au noeud <quote>maître</quote> doit être limité aux 
              applications qui en ont réellement besoin; Les utilisateurs effectuant de 
              l'extraction de données ("reporting") ont généralement des droits plus limités
              sur le noeud maître que sur les noeuds abonnés.</para>
            </listitem>
          </itemizedlist>
        </listitem>          
      </itemizedlist>
    </listitem>  
    <listitem id="slonyuser">
      <para> Noms d'utilisateur spécifiques à &slony1;. </para>

      <para> Il s'est avéré utile de définir un utilisateur <command>slony</command> employé
      uniquement par &slony1;, un utilisateur distinct de l'utilisateur générique 
      <command>postgres</command> ou <command>pgsql</command>.  </para>

      <para> Lorsque toutes sortes d'activités de <quote>maintenance</quote>
      automatiques, telles que les <command>vacuum</command> et les sauvegardes,
      sont effectuées avec l'<quote>identité</quote> de l'utilisateur &postgres;
      , cela peut assez facilement provoquer des problÚmes d'inter-blocages ("deadlocks").</para>

      <para> Par exemple, une série de <command>vacuums</command> qui sont 
      lancés de maniÚre inattendue sur une base de donnée avec un gros événement
      <command>SUBSCRIBE_SET</command> en cours d'exécution pourra entraîner des
      inter-blocages qui annuleront plusieurs heures de travail de copie de données.
      </para>

      <para> À l'inverse, si les différentes opérations de maintenance sont exécutées par
      différents utilisateurs, vous pourrez assurer la réussite d'une opération vitale 
      telle que <command>SUBSCRIBE_SET</command>, en bloquant les autres utilisateurs
      au niveau du fichier <filename>pg_hba.conf</filename>, et autorisant uniquement
      l'utilisateur slony, ce qui réduit considérablement le risque de problÚmes lors d'un
      processus de souscription.</para>
    </listitem>
    <listitem>
      <para> Configuration des chemins</para> 
      <para> La section sur les <link linkend="plainpaths"> voies de communications
      </link> évoque les problÚmes liés aux connexions réseau nécessaire au 
      bon fonctionnement de &slony1;.</para>
    </listitem>

    <listitem>
      <para> Réduction des super-pouvoirs </para>
      <para> Traditionellement, on considÚre que <quote>&slony1; a besoin 
      de connexions en mode super-utilisateurs</quote>. Cela n'est pas
      totalement vrai et si l'usage excessif de comptes super-utilisateurs
      pose problÚme, il est possible de réduire nettement cet usage.</para>

      <para> Il est vrai que chaque  &lslon; <emphasis>doit</emphasis>
      avoir une connexion super-utilisateur afin de gérer le noeud dont il opÚre.
      Il doit pouvoir modifier le catalogue systÚme afin de mettre en place les 
      souscriptions et  procéder aux modifications 
      (<emphasis>par exemple</emphasis> - pour exécuter <xref linkend="stmtddlscript"/> et 
      d'autres évÚnement qui peuvent modifier le rÎle d'une tables répliquées sur un noeud 
      local).  </para>

      <para> Toutefois, les connexions que les processus &lslon; ouvrent vers d'autres noeuds
      afin d'accéder aux événements et aux souscriptions n'ont pas besoin d'avoir 
      d'autant de permissions. Ainsi, on peut mettre en place un  <quote>utilisateur 
      faible</quote> assigné à toutes les requêtes <xref linkend="stmtstorepath"/>.
      Les permissions minimales de cet utilisateur, appellons-le 
      <command>weakuser</command>, sont les suivantes :</para>
      <itemizedlist>
        <listitem>
          <para> Il doit avoir accÚs en lecture sur le namespace spécifique de &slony1;</para>
        </listitem>
        <listitem>
          <para> Il doit avoir accÚs en lecture sur toutes les tables et les séquences de ce namespace</para> 
        </listitem>
        <listitem>
          <para> Il doit avoir accÚs en écriture sur la table <envar>sl_nodelock</envar> et la séquence <envar>sl_nodelock_nl_conncnt_seq</envar> </para> 
        </listitem>
        <listitem>
          <para> Lors de la souscrition, il doit avoir accÚs en lecture sur toutes les tables répliquées.</para> 
          <para> AprÚs la souscription, il n'est plus nécessaire d'accéder aux tables répliquées. </para>
        </listitem>
        <listitem>
          <para> Il est parfois nécessaire de lire les tables dans pg_catalog; sans qu'on ait pu vérifier
          à quel niveau d'accÚs est convenable. </para>
        </listitem>
      </itemizedlist>
    </listitem>
    <listitem>
      <para> Dans la version 1.3, les tests du <xref linkend="testbed"/>
      permettent l'utilisation d'un utilisateur faible (<envar>WEAKUSER</envar>) afin de 
      tester si les permissions définies sont suffisantes pour supporter la réplication.</para>
    </listitem>
    <listitem>
      <para> La section sur les <link linkend="listenpaths"> voies d'écoute </link>
      parle des problÚmes entourant la table <xref linkend="table.sl-listen"/>.</para>

      <para> A partir la version &slony1; 1.1, le contenu de cette table 
      était calculé automatiquement en se basant sur les informations
      dont disposait &slony1; ce qui devrait supprimer les problÚmes 
      rencontrés. Beaucoup de problÚmes de communication inexplicables,
      avec des noeuds qui n'arrive pas à se parler alors que c'est techniquement 
      possible, étaient du à une configuration incorrecte des voies d'écoutes.</para>
    </listitem>

    <listitem>
      <para> Utilisez <filename>test_slony_state.pl</filename> pour rechercher
      les problÚmes de configuration.</para>

      <para>Il s'agit d'un script Perl qui se connecte à un noeud &slony1; puis 
      parcours la configuration &slony1; à la recherche de différentes conditions
      qui indique la présence de problÚmes, en particulier :</para>
      <itemizedlist>
        <listitem><para>le gonflement de certaines tables de congfiguration;</para></listitem>
        <listitem><para>l'analyse des voies d'écoute;</para></listitem>
        <listitem><para>l'analyse de la propagation et de la confirmation des événements.</para></listitem>
      </itemizedlist>

      <para> Si, de maniÚre mystérieuse, la réplication <quote>ne marche pas</quote>, cet outil
      peut vérifier beaucoup de problÚmes potentiels pour vous. </para>
    </listitem>
    <listitem>
      <para> Configurer &lslon; </para> 

      <para> A partir de la version 1.1, la configuration de &lslon; 
      peut être définie par ligne de commande ou dans des fichiers de
      configuration. De <quote>bonnes</quote> pratiques sont 
      conseillédans les deux cas :
      </para>
      <itemizedlist>
        <listitem>
          <para> Configuration via les options en ligne de commande</para> 

          <para> Cette approche à le mérite de rendre visible dans
          l'environnement systÚme toutes les options actives.
          (Ainsi s'il y en a beaucoup cela peut devenir pénible
          Ã  lire)</para>

          <para>Malheureusement, si vous invoquer &lslon; Ã  partir d'une
          ligne de commande, vous pouvez <emphasis>oublier</emphasis> d'inclure
          la configuration de &logshiplink; et ainsi détruire les
          séquences de logs pour les noeuds de log shipping.</para>
        </listitem>
        <listitem> 
          <para> A la différence  des options en ligne de
          commande les options actives ne sont <emphasis>pas</emphasis> visible.
          Elles peuvent seulement être positionnées à partir u nom
          et du contenu du fichier de configuration de &lslon;, et ne 
          refléteront pas les changements apparus dans le fichier de
          configuration.</para>

          <para> En plaçant les options dans un fichier, vous n'oublierez
          aucune, ce qui est plus sur pour &logshiplink;. </para>
        </listitem>
      </itemizedlist>
    </listitem>
    <listitem>
      <para> Taches à faire loque l'on abonne un noeud </para>
      <para> Lorsqu'un nouveau noeud exécute l'événement <command>COPY_SET</command>
      sur un grand ensemble de réplication (<emphasis>par
      exemple</emphasis> - un ensemble qui nécessite un abonnement de
      plusieurs heures) il est prouvé qu'il est souhaitable de
      verrouiller l'accÚs au noeud pour tous les utilisateurs
      autres que <command>slony</command> car :</para>
      <itemizedlist>
        <listitem>
          <para> Les applications s'exécutent sur des 
          données partiellemen copiées qui ne seront pas
          consistantes.</para> 
        </listitem>
        <listitem>
          <para>Il est possible que certaines applications (et
          certains scripts de maintenance) soumettent une combinaison 
          de requêtes qui placeront le systÚme dans une situation
          d'inter-blocage ("deadlock"), ce qui annulera l'événement 
          <command>COPY_SET</command>, et impliquera le ré-abonnement
          complet du noeud.</para>
        </listitem>
      </itemizedlist>
    </listitem>
</itemizedlist>    
<para> Il <emphasis>peut</emphasis> être intéressant de
désactive la fonctionnalité<function>fsync</function> de &postgres;
pendant le copie des données, car cela améliorera les performances,
et en cas d'échec lors de l'évÚnement
<command>COPY_SET</command>, vous pourrez redémarrer avec un copie entiÚre de l'ensemble de réplication.</para>
<itemizedlist>            
    <listitem>
      <para> Gestion de slonik </para> 
      <para> Les notes sur <link linkend="usingslonik">l'utilisation de 
      Slonik </link> décrivent certaines lessons apprises en
      gérant un grand nombre de scripts <xref linkend="slonik"/>.</para>
      <para> Voici les principes importants se sont dégagés lors de
      la création de ces scripts :</para>
      <itemizedlist>
        <listitem>
          <para>Utiliser des fichiers <quote>préambule</quote>
          est <emphasis>hautement recommandé</emphasis> car cela implique
          que vous utilisiez et    réutilisiez des
          préambules vérifié maintes fois.</para>
        </listitem>
        <listitem>
          <para>Toute opportunité de générer automatiquement
          la configuration soit en la récpérant dans une base de
          données, soit en utilisant un script de génération vous
          aidera à éviter les erreurs humaines.</para>
        </listitem>
      </itemizedlist>
    </listitem>
    <listitem>
      <para>GÚrer un trÚs grand ensemble de réplication</para>
      <para> Certains utilisateurs ont bâti des réplications sur des
      ensembles de plusieurs dizaines, voire plusieurs centaines de 
      gigabytes, ce qui ajoute des <quote>contraintes</quote> sur le
      systÚme, n particulier lorsqu'il faut plusieurs jours pour
      effectuer un évÚnement  <command>COPY_SET</command>.
      Voici quelques principes qui ont été définis
      pour gérer ce genre de situations.</para>
    </listitem>
    <listitem>
      <para> Supprimer tous les index autres que les index 
      primaire lorsque l'évÚnement en<command>COPY_SET</command>
      est exécuté.</para>
  
      <para> Lorsque les données sont copiées dans une table qui
      dispose d'index, &postgres; construit les index de maniÚre
      incrémentale, à la vole.
      Ceci est beaucoup plus lent que simplement copier les donnés
      dans une table puis de recréerchaque index <quote>ex nihilo</quote>,
      car cette derniÚre opération profite de l'avantage de la
      mémoire de tri. </para>
  
      <para> Dans &slony1; version 1.1.5 et dans les versions
      ultérieures, les index sont supprimés et
      recréés automatiquement, ce qui rend caduque ce
      conseil.</para>
    </listitem>
    <listitem>
      <para> Si beaucoup de mises à jour ont lieu lorsque de
      grands ensemble sont copiés, ceci peut mener à un nombre
      énormed'événements<command>SYNC</command> sur le
      noeud qui s'abonne.</para>

      <para>Si un <command> SYNC </command> est généré
      une fois par seconde, ceci conduit à un <quote>retard</quote>
      de plus de 90,000 <command>SYNC</command>s par jour, pendant
      probablement plusieurs jours.  </para>
  
      <para>ParallÚlement
      on constatera une croissance <emphasis>énorme</emphasis>
      des tables <xref linkend="table.sl-log-1"/> et <xref
      linkend="table.sl-seqlog"/>.  
      Malheureusement, une fois que <command>COPY_SET</command> 
      est complété, on constate que les requêtes sur 
      ces tables se font via <command>seq scans</command>,
      mémé si le <command>SYNC</command> ne traite qu'une petite
      partie de ces 90 000 événements<command>SYNC</command>
      la table sera lue dans son ensemble. Dans de tel cas, il
      est possible que le noeud abonné ne rattrape
      jamais le noeud origine.</para> 

      <para> Plusieurs taches peuvent résoudre ce problÚme,
      notamment en réglant avec soin les paramÚtres 
      &lslon; :</para>
    </listitem>
    <listitem>
      <para>Assurez-vous qu'il existe sur le noeud 
      <quote>maître</quote>, un index sur  <function> sl_log_1(log_xid)</function>. 
      S'il n'y en a pas, comme avec les versions de &slony1; 
      inférieure à la version 1.1.1, regardez dans le fichier
      <filename> slony1_base.sql </filename> pour
      la configuration correcte de cet index. </para> 

      <para> Dans les versions 1.2 et suivantes, il y a un processus
      qui ajoute automatiquement les index partiels par numéro de noeud
      d'origine, ce qui est la forme optimale pour ces index.</para>
    </listitem>
    <listitem>
      <para>Sur un noeud abonné, ajouter le nombres
      d'évÚnements<command>SYNC</command>
      traités ensemble, en réglant le paramÚtre 
      <xref linkend= "slon-config-sync-group-maxsize"/> 
      Ã  une valeur lui permettant une portion significative
      de la masse d'événements <command>SYNC</command>. </para> 
    </listitem>
    <listitem>
      <para>Sur le noeud abonné, régler le paramÚtre
      <xref linkend="slon-config-desired-sync-time"/> 
      à 0, car le systÚme de regroupent adaptatif des
      <command>SYNC</command> 
      fonctionne a avec de petits groupes, qui sous certaines
      circonstances, donne de mauvaises performances.
      </para>
    </listitem>
    <listitem>
      <para> Augmenter le 
      <xref linkend="slon-config-sync-interval"/> 
      sur le noeud origine  <xref linkend="slon"/>
      afin que les événement<command>SYNC</command>
      soit générés moins fréquemment.
      Si un <command>SYNC</command> est simplement
      généré une fois par minute plutÎt qu'une fois par seconde, cela
      divisera par soixante le nombre d'évÚnements.
      </para> 
    </listitem>
    <listitem>
      <para> Il faudra probablement utiliser le
      <xref linkend="slon-config-vac-frequency"/> pour 
      désactiver les vacuum lancés par<xref linkend="slon"/>
      afin d'utiliser vos propres scripts de vacuum,
      car il y aura un masse de données non-purgeables pendant 
      que les données seront copiées et 
      que l'abonné commencera à rattraper le fournisseur.
      </para>
    </listitem>
  </itemizedlist>
</sect1>