root/traduc/trunk/slony/concepts.xml

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

<sect1 id="concepts">
<title>Les concepts</title>

<indexterm><primary>concepts et terminologie</primary></indexterm>

<para>Afin de mettre en place une réplication &slony1;, il est nécessaire de comprendre les
  principales abstractions utilisées : </para>

<itemizedlist>
        <listitem><para>Cluster,</para></listitem>
        <listitem><para>Noeud ("node"),</para></listitem>
        <listitem><para>Ensemble de réplication ("replication set"),</para></listitem>
        <listitem><para>Origine ("Origin"), Fournisseurs ("Providers") et Abonnés ("Subscribers"),</para></listitem>
        <listitem><para>Les démons slon,</para></listitem>
        <listitem><para>La commande slonik</para></listitem>
</itemizedlist>

<para> Il est également nécessaire de connaître quelques mots de russe :</para>
<itemizedlist>
<listitem><para>slon signifie <quote>éléphant</quote> en russe,</para></listitem>
<listitem><para>slony est le pluriel de slon, et désigne ainsi un groupe d'éléphants</para></listitem>
<listitem><para>slonik désigne un <quote>petit éléphant</quote></para></listitem>
</itemizedlist>

<para> L'utilisation de ces termes dans &slony1; est un <quote>coup de chapeau</quote> 
  Ã  Vadim Mikheev, qui est l'auteur du prototype <application>rserv</application> 
  qui inspira une partie des algorithmes utilisé dans &slony1;.</para>

<sect2>
<title>Cluster</title>
<indexterm>
 <primary>cluster</primary>
</indexterm>

<para>Selon &slony1;, un <quote>cluster</quote> est ensemble nommé d'instances de bases 
  de données &postgres;; Une réplication a lieu entre ces bases.</para>

<para>Le nom du cluster est spécifié dans chaque script Slonik via la directive :</para>
<programlisting>
cluster name = 'quelque_chose';
</programlisting>

<para>Si le nom du cluster est <envar>plop</envar>, alors &slony1;
créera, dans chaque instance du cluster, le schéma <envar>_plop</envar>.</para>
</sect2>
<sect2><title>Noeud</title>
<indexterm>
<primary>noeud</primary>
</indexterm>

<para>Un noeud &slony1; est un base &postgres; nommée qui participe à la réplication.</para>

<para>Le nom du noeud est défini au début de chaque script Slonik, avec la directive :</para>
<programlisting>
 NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
</programlisting>

<para>La ligne <xref linkend="admconninfo"/> précise les informations
  de connexion qui seront utilisées par la fonction libpq 
<function>PQconnectdb()</function>.</para>

<para>Ainsi un cluster &slony1; se compose :</para>
<itemizedlist>
        <listitem><para> d'un nom de cluster</para></listitem>
        <listitem><para> d'un ensemble de noeuds &slony1;, qui disposent chacun d'un schéma 
            portant le nom du cluster</para></listitem>
</itemizedlist>
</sect2>
<sect2><title>Ensemble de réplication</title>
<indexterm>
<primary>Ensemble de réplication</primary>
</indexterm>

<para>Un ensemble de réplication est défini comme un ensemble de tables et de séquences qui 
  doivent être répliquées entre plusieurs noeuds dans un cluster &slony1;.</para>

<para>Vous pouvez avoir plusieurs sets, et le <quote>flux</quote> de réplication
  n'est pas nécessaire identique pour tous les ensembles.</para>
</sect2>

<sect2><title> Origine, Fournisseurs et Abonnés</title>
<indexterm>
<primary>Noeud d'origine</primary>
</indexterm>
<indexterm>
<primary>Noeud fournisseur</primary>
</indexterm>

<para>Chaque ensemble de réplication a un noeud d'origine, qui est le <emphasis>seul</emphasis> endroit
  où les applications sont autorisées à modifier les données répliquées. On peut aussi 
  rencontrer le terme <quote>noeud maître</quote>; Il s'agit de noeud principal qui 
  fournit les données.
</para>

<indexterm>
<primary>Noeud Abonné</primary>
</indexterm>

<para>Les autres noeuds du cluster s'abonne à l'ensemble de réplication,
  ce qui indique qu'ils veulent recevoir les données.
</para>

<para>Le noeud d'origine ne sera jamais considéré comme un 
<quote>abonné</quote> (On ignore ici le cas ou le cluster est restructuré
et où l'origine est explicitement déplacée sur un autre noeud).
Mais &slony1; supporte la notion d'abonnements en cascade, c'est à dire
qu'un noeud qui est abonné à un ensemble de réplication, peut également se
comporter comme un <quote>fournisseur</quote> du même ensemble de réplication
pour d'autres noeuds du cluster.</para>
</sect2>

<sect2><title>Le démon slon</title>

<indexterm><primary>démon slon</primary></indexterm>

<para>Pour chaque noeud du cluster, il y a un processus <xref
linkend="slon"/> qui gÚre l'activité de réplication pour le noeud.
</para>

<para> <xref linkend="slon"/> est un programme implémenté en C qui traite les 
  évÚnements de réplication. Il y a deux principales sortes d'événements :
</para>

<itemizedlist>

<listitem><para>Les évÚnements de configuration</para>

<para> Ils se produisent en général lorsqu'un script <xref linkend="slonik"/> est exécuté,
  et qu'il modifie la configuration du cluster. </para>
</listitem>

<listitem><para> Les événements <command>SYNC</command></para>

<para> Les mises à jour des tables répliquées sont regroupées dans des événements <command>SYNC</command>s;
  Ces groupes de transactions sont appliquées ensemble sur les noeuds abonnés.
</para>
</listitem>
</itemizedlist>
</sect2>

<sect2><title>La commande slonik</title>

<indexterm><primary>La commande slonik</primary></indexterm>

<para> La commande <xref linkend="slonik"/> traite des scripts
  écrits dans un <quote>langage spécial</quote> qui est utilisé pour
  soumettre des événements de configuration du cluster &slony1; cluster.
  Cela comprend des actions telles que l'ajout et la suppression de noeuds, 
  la modifications des voies de communications, l'ajout ou la suppression d'abonnements.
</para>
</sect2>
</sect1>