root/traduc/trunk/slony/intro.xml

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

<sect1 id="introduction">
<title>Introduction à &slony1;</title>

<indexterm><primary> introduction à &slony1; </primary></indexterm>

<sect2> <title>Qu'est ce que &slony1; ?</title>

<para>&slony1; est systÚme de réplication entre <quote>un maître et de multiple esclaves</quote>
qui supporte les cascades et la promotion d'un esclave en maître.  
Le schéma directeur du développement de &slony1; est la création 
d'un systÚme maître-esclave qui inclue les fonctionnalités nécessaire
pour répliquer de grandes bases de données avec un nombre raisonnable
d'esclaves. <quote>Raisonnable,</quote> dans ce contexte, signifie 
une douzaine de serveurs.  Si le nombre de serveurs évolue au-delà de
cette limite, le coût des communications augmentent de maniÚre prohibitive, 
et le bénéfice d'avoir de multiple serveurs s'amenuise.</para>

<para> Voir la section <xref linkend="slonylistenercosts"/> pour une 
  analyse plus détaillées des coûts associés à l'augmentation du 
  nombre de noeuds.</para>

<para> &slony1; est un systÚme conçu pour les datacenters et sites de 
  sauvegardes, où le fonctionnement des opérations est que tous les
  noeuds sont disponibles en permanence, et où tous les noeuds peuvent
  être sécurisés. Si vous avez des noeuds qui risquent réguliÚrement d'être 
  coupés du réseau, ou si la sécurité de vos noeuds ne peut pas 
  être garantie,  &slony1; n'est probablement pas la solution de réplication
  idéale pour vous.</para>

<para> Voici notamment quelques exemples de cas où &slony1; ne sera probablement
  pas adapté :

<itemizedlist>
<listitem><para> Les sites dont la connectivité est <quote>instable</quote>
</para></listitem>
<listitem><para> La réplication entre des noeuds qui ne sont pas toujours interconnectés</para></listitem>

<listitem><para> Répliquer une base de tarification à partir d'un serveur central vers 
    l'équipe commerciale qui s'y connecte périodiquement pour en extraire les mise à jour.
  </para></listitem>

<listitem><para> Les sites où les changements de configuration sont faits de
    maniÚre hasardeuse.</para></listitem>

<listitem><para> Un situation <quote>d'hébergement web</quote> où les 
    utilisateurs peuvent de maniÚre indépendante et arbitraire changer les
    schémas des données.
    </para>
  </listitem>
  </itemizedlist>
</para>
<para> Il existe une extension de <link linkend="logshipping"> log shipping par fichier</link>
  qui permet de regrouper les mises à jour dans des fichiers.
  Ainsi, les fichiers de mises à jours peuvent être distribués 
  par différents moyens sans avoir à attendre d'accusé de réception
  entre les noeud fournisseur et les noeuds qui sont abonnés au 
  <quote>log shipping</quote>. Le noeuds abonnés au <quote>Log
shipping</quote> n'augmente pas les coûts de communication être
les noeuds &slony1;.</para>

<para> Mais &slony1;, ayant une seule origine par ensemble de données répliqué,
  n'est pas adapté pour effectuer de la réplication <emphasis>réellement</emphasis> asynchrone
  et multi-directionnelle. Pour celles et ceux qui recherche une 
  <quote>réplication asynchrone multi-maîtres avec résolution des conflits</quote>
  telle que ce que fournit <productname>Lotus
<trademark>Notes</trademark></productname> ou les protocoles de <quote>synchronisation</quote>
présents sur les systÚmes PalmOS, il est nécessaire de se tourner vers d'autres logiciels.
</para> 

<para> Il existe également d'autres modÚles de réplication qui ne sont pas sans avantages,
  mais qui permettent des scénarios de réplication <emphasis>différents</emphasis> 
  de ce que &slony1; propose.</para>

</sect2>

<sect2><title>Pourquoi proposer encore un autre systÚme de réplication ?</title>

<para>&slony1; est né de l'idée de créer un systÚme de réplication qui ne soient
  pas lié à une version spécifique de &postgres;, pour qu'il puisse être lancé
  et arrêté sur une base existante sans besoin d'effectuer un cycle d'export/import
  des données.</para>

</sect2>

<sect2><title> Ce que &slony1; n'est pas</title>

<itemizedlist>
<listitem><para>&slony1; n'est pas un systÚme de gestion de réseau.</para></listitem>

<listitem><para> &slony1; n'a aucune fonctionnalité permettant de détecter
    la perte d'un noeud, ni de transformer automatiquement un noeud en maître
    ou en noeud origine.</para>

<para> Il est toutefait possible que vous ayez besoin de ce type de mécanisme;
  cela vous demandera de combiner des outils réseau qui évaluent 
 <emphasis>selon vos critÚres</emphasis> quels noeuds vous considérez comme
<quote>actifs</quote> et quels noeuds vous considérez comme <quote>morts</quote>,
ainsi qu'une politique locale pour déterminer ce qu'il faut faire dans telle ou telle circonstance.
&slony1; ne vous impose aucune politique.</para></listitem>

<listitem><para>&slony1; n'est pas un systÚme de réplication multi-maîtres; 
    ce n'est pas un gestionnaire de connexions, et il ne vous apportera pas 
    le café et les croissants le matin.</para></listitem>

</itemizedlist>

<para>Ceci étant dit, il existe des outils à votre disposition pour
  simplifier certaines de ces opérations, et il existe un projet en cours
  de développement, <productname>Slony-II</productname>, pour fournir
  des mécanismes <quote>multi-maîtres</quote>. Mais cela constitue 
  un projet différent et séparé, implémenté de façon trÚs différente
  de &slony1;, et attentes à propos de &slony1; ne doivent pas se baser 
  sur l'espoir placé dans de futurs projets.</para></sect2>

<sect2><title> Pourquoi &slony1; ne fait pas de bascule automatique en cas de panne («fail over») ?
</title>

<para>Déterminer si un noeud est en  <quote>échec</quote> est de la responsabilité
  d'un logiciel de surveillance de réseau, pas de &slony1;. La configuration,
  les mécanismes de bascule et les politiques de reprise sur panne sont 
  différent selon les sites. Par exemple, la surveillance avec des NICs redondants
  et les mécanismes de haute-disponibilité intelligents qui garantissent
  un changement d'adresse réseau à la volée sans conflit et une isolation 
  du noeud <quote>en échec</quote>, dépendent de la configuration du réseau,
  des choix matériels et de la combinaison entre les logiciels et les appareils
  utilisés. Tout cela appartient clairement au domaine de la gestion de réseau,
  pas à celui de  &slony1;.</para>

<para> De plus, choisir comment se comporter selon 
<quote>l'état</quote> du cluster concerne la politique commerciale locale,
en particulier si on considÚre qu'une <link
linkend="stmtfailover"><command>bascule en cas de panne</command></link> ( « fail over » ) nécessite
d'isoler le noeud en échec. Si &slony1; imposait une politique de bascule en cas de panne
aux utilisateurs, cela entrerait parfois en conflit avec des
intérêts commerciaux et &slony1; serait parfois une solution inadaptée.</para>

<para>En conséquence, laissons &slony1; faire ce qu'il fait de mieux : fournir un service de
  réplication de bases de données.</para></sect2>

<sect2><title> Limitations actuelles</title>

<indexterm><primary>limitations de &slony1;</primary></indexterm>

<para>&slony1; ne propage pas les changements du schéma de données,
  et ne réplique non plus les objets volumineux ( «large objects» )
  Il y a une raison unique et commune à ces limitations :
  &slony1; collecte les mises à jours en utilisant des triggers, et
  ni les changements de schéma, ni les opérations sur les objets volumineux,
  ni les requêtes <command>TRUNCATE</command> ne sont capables de 
  déclencher des triggers pour informer &slony1; lorsque ce genre 
  de modification a lieu. Ainsi les seuls objets que &slony1; peut répliquer
  sont les tables et les séquences.  </para>

<para> Notons que <emphasis>l'utilisation</emphasis> de triggers implique
  quelques <emphasis>retoucher</emphasis> supplémentaires sur ces triggers.
Sur le noeud <quote>origine</quote> pour chaque table répliquée, on ajoute un trigger
supplémentaire qui lance la procédure stockée  <xref
linkend="function.logtrigger"/>.  
Sur chaque noeud abonné, les tables sont complétées avec un trigger qui lance 
la fonction  <xref
linkend="function.denyaccess"/>; cette fonction empêche toute mise à jour
sur les tables répliquées à l'exception de celles effectuées par
le processus <xref linkend="slon"/>.
De plus, toutes les <emphasis>autres</emphasis> triggers et rÚgles 
sur les tables répliquées sont <emphasis>supprimés</emphasis> sur
les noeuds abonnés; Ceci est réalisé en faisant pointant ces tables,
dans le catalogue systÚme, vers les index des clefs primaires 
plutÎt que sur la table elle-même.
Cela s'apparente à une <quote>corruption</quote> du dictionnaire de données,
et cela explique pourquoi on ne peut pas utiliser directement 
 <application>pg_dump</application> pour exporter le schéma sur les 
 noeuds abonnés. </para>

<para>Il est possible de propager d'autres types de modifications des bases
  avec &slony1;, notamment les ordres DDL, si vous les effectuer via la fonction
  de <application>slonik</application> nommée <xref
linkend="stmtddlscript"/>.  Ceci ne peut pas se faire 
<quote>automatiquement</quote>; en tant qu'administrateur de base de données,
vous devez superviser les scripts SQL DDL et les soumettre via  <xref
linkend="stmtddlscript"/> car il existe un certain nombre de 
piÚges à éviter concernant les <link
linkend="ddlchanges">.</link> </para>

<para>Si vous ne pouvez pas superviser ces modifications, vous devrez peut-être 
  envisager l'utilisation du mécanisme <acronym>PITR</acronym> (Point In
Time Recovery) de &postgres; (version 8.x), avec lequel les journaux
<acronym>WAL</acronym> sont répliqués sur des noeuds distants.
Malheureusement cette solution à deux limitations majeures :

<itemizedlist>
        
<listitem><para> Le mécanisme PITR replique <emphasis>tous</emphasis> les changements de
<emphasis>toutes</emphasis> les bases de données; vous ne pouvez pas 
exclure les données qui ne sont pas intéressantes;</para></listitem>

<listitem><para> Un réplicat PITR reste endormi jusqu'à ce que les journaux
    soient appliqués et que la base soit relancée. Vous ne pouvez pas
    utiliser la base et appliquer les mises à jour simultanément.
    Cela revient à avoir un <quote>serveur de secours</quote> que
    vous ne pouvez utiliser sans stopper la réplication.</para></listitem>

</itemizedlist></para>
</sect2>

<sect2><title>ModÚles de réplication</title>

<indexterm><primary>modÚles de réplication</primary></indexterm>

<para>%Il beaucoup de modÚles de réplication différents; il est 
  qu'un systÚme de réplication puisse répondre à toutes les attentes
  de tous les utilisateurs.</para>

<para> &slony1; implémente un modÚle particulier, la réplication asynchrone,
  en utilisant des triggers pour collecter les mises à jour sur les tables,
  sur une <quote>origine</quote> unique, puis réplique ces mises à jour
  sur de multiple <quote>abonnés</quote>, y compris les abonnés en cascade.</para>

<para> Il existe de de nombreaux autres modÚles de réplication
  qui sont <emphasis> différent </emphasis> de celui-ci; il est 
  important de souligner que d'autres approches sont possibles. 
  &slony1; n'est certainement pas la seule approche, et pour certaines
  applications, ce n'est <emphasis> pas </emphasis> la meilleur approche. </para>

<itemizedlist> 
<listitem><para> Réplication synchrone entre une origine unique et plusieurs abonnés</para>

<para> Dans un systÚme synchrone, les mises à jour ne peuvent pas être committées
  sur l'origine tant qu'elles n'ont pas été acceptées par les noeuds abonnés.
  Ceci renforce la sécurité en évitant les risques de répudiation, car les mises 
  à jour ne sont pas effectuées sans avoir été confirmées ailleurs. Malheureusement,
  la nécessité d'appliquer simultanément les changements sur de multiple emplacement
  constitue un frein sur les performances. </para>

<para> Cette approche est similaire au modÚle basé sur le commit en deux phases ( NdT : « two phase commit » )
  implémenté dans le protocole de gestion de transaction XA.</para>
</listitem>

<listitem><para> Réplication synchrone entre plusieurs origines et plusieurs abonnés </para> 

<para> Ceci est le modÚle implémenté dans l'hypothétique systÚme 
<productname>Slony-II</productname>.  Les systÚmes de réplication synchrones
<quote>souffrent</quote> de problÚmes de performances, car les mises à jour doivent
être acceptées par tous les noeuds avant d'être appliquées.</para>

<para> En pratique, il est inutile de faire fonctionner un systÚme de réplication
  synchrone sur un réseau longue distance (WAN).</para>
</listitem>

<listitem><para> Réplication asynchrone multi-maîtres avec résolution/prévention des conflits</para>

<para> Le systÚme de réplication le plus répandu utilisant ce modÚle est probablement
  le systÚme <productname>PalmOS HotSync</productname>.
<trademark>Lotus Notes</trademark> fournit également un systÚme de réplication
qui fonctionne de la même maniÚre.</para>

<para> Le <quote>problÚme</quote> caractéristique avec ce 
style de réplication est que des conflits peuvent apparaître
lorsque des utilisateurs mettent à jour le même enregistrement 
de différente maniÚre sur différents noeuds.</para>

<para> Dans le cas de <productname>HotSync</productname>, si un conflit 
  est provoqué par la mise à jour simultanée d'un même enregistrement,
  la <quote>résolution</quote> se résume à créer un deuxiÚme enregistrement
  pour témoigner des deux mises à jours, puis laisser l'utilisateur résoudre
  le conflit à la main. </para>

<para> Certains systÚmes de réplication multi-maîtres asynchrones essaient
  de résoudre les conflits en trouvant de moyens pour appliquer partiellement
  les mises à jour. Par exemple, dans le cas de la mise à jour d'un adresse,
  si un autre utilisateur tente de mettre à jour le nom de la rue, alors le
  systÚme de résolution des conflits essaie d'appliquer les mises à jour
  dans un ordre non-conflictuel. On peut considérer cette méthode comme
  une forme de <quote>partitionnement de table</quote> où l'on considÚre la
  base de données comme une table constituée de plusieurs <quote>sous-tables</quote>. </para>

<para> Les systÚmes de résolution de conflit nécessaire presque toujours
  une bonne connaissance du domaine de l'application, ce qui implique
  qu'ils ne peuvent résoudre des conflits automatiquement uniquement si
  vous leur indiquez une politique de résolution. S'ils rencontrent
  un conflit et qu'il n'existe pas de politique définie, la réplication 
  s'arrête jusqu'à ce que quelqu'un résolve le conflit à la main.</para>
</listitem>

</itemizedlist>

</sect2>
</sect1>

<sect1 id="slonylistenercosts"><title> Coûts de communications avec &slony1;</title>

<para>Le coût de communications augmente de façon quadratique dans plusieurs 
directions lorsque le nombre de noeuds de réplication du cluster
grandit.  Notons les relations suivantes :

<itemizedlist>

<listitem><para> Il est nécessaire que les entrées de la table <xref
linkend="table.sl-listen"/> autorise toutes les connexions entre tous les noeuds.
Dans le pluspart des cas, cela n'est pas trÚs volumineux, mais cela signifie tout
de même qu'il faut définir n(n-1) voies de communications.
</para></listitem>

<listitem><para> Chaque événement SYNC appliqué doit être annoncé à 
    tous les noeuds participants à la réplication de l'ensemble de 
    données, afin que chaque noeud sache qu'il est possible de 
    purger les données des tables  <xref linkend="table.sl-log-1"/> et <xref
linkend="table.sl-log-2"/>, car n'importe quel noeud <quote>fournisseur</quote>
    peut potentiellement devenir un <quote>maître</quote> à tout moment.
    On peut s'attendre à que les messages SYNC ne soient propagés que sur 
    n/2 noeuds pour atteindre leur destination; ce qui implique que
    chaque SYNC est transmis n(n/2) fois.  A nouveau, cela montre
    que la croissance des coûts de communication est quadratique selon
    le nombre de noeuds dans le cluster.</para></listitem>

</itemizedlist></para>

<para>Tout ceci prouve qu'il n'est pas judicieux de bâtir un grand réseau de communication 
  pour supporter un systÚme de réplication contenant beaucoup de noeuds.
  Jusqu'Ã  une demi-douzaine de noeuds cela semble raisonnable; Ã  chaque fois que 
  le nombre de noeuds double, les temps de communications quadruplent.</para>
</sect1>