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 la terminologie utilisée&nbsp;:
</para>

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

<para>
  Il est également nécessaire de connaître quelques mots de russe&nbsp;:
</para>

<itemizedlist>
  <listitem><para>slon signifie <quote>éléphant</quote> en russe&nbsp;;</para></listitem>
  <listitem><para>slony est le pluriel de slon, et désigne ainsi un groupe
    d'éléphants&nbsp;;</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&nbsp;:
</para>

<programlisting>
cluster name = quelque_chose;
</programlisting>

<para>
  Si le nom du cluster est <envar>plop</envar>, alors &slony1; crée, dans
  chaque instance du cluster, le schéma <envar>_plop</envar>.
</para>

</sect2>

<sect2><title>Noeud</title>
<indexterm><primary>n&oelig;ud</primary></indexterm>

<para>
  Un n&oelig;ud &slony1; est une base &postgres; nommée qui participe à la
  réplication.
</para>

<para>
  Le nom du n&oelig;ud est défini au début de chaque script Slonik, avec la
  directive&nbsp;:
</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&nbsp;:
</para>

<itemizedlist>
  <listitem><para>d'un nom de cluster&nbsp;;</para></listitem>
  <listitem><para> d'un ensemble de n&oelig;uds &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 n&oelig;uds dans un
  cluster &slony1;.
</para>

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

</sect2>

<sect2><title>Origine, Fournisseurs et Abonnés</title>
<indexterm><primary>N&oelig;ud d'origine</primary></indexterm>
<indexterm><primary>N&oelig;ud fournisseur</primary></indexterm>

<para>
  Chaque ensemble de réplication a un n&oelig;ud 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>n&oelig;ud maître</quote>. Il s'agit du n&oelig;ud principal qui
  fournit les données.
</para>

<indexterm><primary>N&oelig;ud Abonné</primary></indexterm>

<para>
  Les autres n&oelig;uds du cluster s'abonnent à l'ensemble de réplication, ce
  qui indique qu'ils veulent recevoir les données.
</para>

<para>
  Le n&oelig;ud 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 n&oelig;ud).
  Mais &slony1; supporte la notion d'abonnements en cascade, c'est-à-dire
  qu'un n&oelig;ud 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 n&oelig;uds du cluster.
</para>

</sect2>

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

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

<para>
  <xref linkend="slon"/> est un programme implémenté en C qui traite les
  évènements de réplication. Il y a deux principaux types d'événements&nbsp;:
</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>&nbsp;; ces groupes de transactions
      sont appliquées ensemble sur les n&oelig;uds 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;. Cela comprend des actions telles que
  l'ajout et la suppression de n&oelig;uds, la modification des voies de
  communications, l'ajout ou la suppression d'abonnements.
</para>

</sect2>

</sect1>