Permalink
Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
202 lines (157 sloc) 6.2 KB
<?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>