Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Branch: master
Fetching contributors…

Cannot retrieve contributors at this time

142 lines (125 sloc) 6.02 kB
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="slonstart"> <title>Les démons Slon</title>
<indexterm><primary>exécuter le démon slon</primary></indexterm>
<para>
Les programmes qui effectuent concrètement la réplication &slony1; sont les
démons <application>slon</application>.
</para>
<para>
Vous devez lancer une instance <xref linkend="slon"/> sur chaque n&oelig;ud
du cluster &slony1;, que ce n&oelig;ud soit considéré comme un maître ou
comme un esclave. Sous &windows;, l'exécution en tant que service est
légèrement différente. Un service slon est installé et un fichier de
configuration est enregistré pour chaque n&oelig;ud qui devra être servi par
la machine. Le service principal gère alors lui-même les demons slons
individuels. Puisque qu'une commande <command>MOVE SET</command> ou
<command>FAILOVER</command> peut modifier le rôle des n&oelig;uds, slon doit
fonctionner pour tous les n&oelig;uds. Il n'est pas essentiel que ces démons
soient hébergé sur un hôte particulier mais quelques principes méritent
d'être considérés&nbsp;:
<itemizedlist>
<listitem>
<para>
Chaque démon <application>slon</application> doit être capable de
communiquer rapidement avec la base de données dont il est le
<quote>contrôleur</quote>. Ainsi, si un cluster &slony1; s'étend sur un
réseau longue distance (WAN), chaque processus slon doit être exécuté
sur ou près de la base de données qu'il gère. Si vous enfreignez cette
règle, aucun désastre ne s'en suivra mais la latence induite pour
surveiller les événements sur son propre n&oelig;ud impliquera que le
démon slon effectuera une réplication <emphasis>un peu</emphasis> moins
rapide.
</para>
</listitem>
<listitem>
<para>
Les meilleurs résultats sont obtenus en exécutant chaque démon
<application>slon</application> sur le serveur de base de donnée qu'il
contrôle. S'il est exécuté dans un réseau local rapide, les
performances ne seront pas dégradées de manière notable.
</para>
</listitem>
<listitem>
<para>
Il est intéressant de lancer plusieurs processus slon sur une machine
unique car il est plus simple de surveiller les journaux applicatifs
et les tables des processus lorsqu'ils se trouvent au même endroit.
Cela évite également de devoir se connecter à plusieurs hôtes pour
lire les journaux applicatifs ou pour redémarrer les instances
<application>slon</application>.
</para>
</listitem>
</itemizedlist>
</para>
<warning>
<para>
<emphasis>Ne lancez pas</emphasis> un démon slon devant gérer un n&oelig;ud
à travers un lien WAN, si possible. Tout problème avec ce lien peut tuer
les connexions et ainsi laisser des connexions <quote>zombies</quote> sur
les n&oelig;uds qui subsisteront (de manière générale) pendant environ deux
heures. Ceci empêche le démarrage d'un autre slon, comme cela est décrit
dans la <link linkend="faq">FAQ</link> au sein de la section sur les <link
linkend="multipleslonconnections">connexions slon multiples</link>.
</para>
</warning>
<para>
Historiquement, les processus <application>slon</application> ont été plutôt
fragiles, défaillant dès qu'ils rencontraient une erreur significative. Ce
comportement impliquait l'utilisation de <quote>chiens de garde</quote> qui
surveillent les démons afin de s'assurer que, si un
<application>slon</application> s'arrête, il soit remplacé par un autre.
</para>
<para>
Il existe deux scripts de <quote>chiens de garde</quote> actuellement
disponible dans l'arborescence des sources de &slony1;&nbsp;:
<itemizedlist>
<listitem>
<para>
<filename>tools/altperl/slon_watchdog</filename> - une version
<quote>précoce</quote> qui contient basiquement une boucle autour de
l'invocation de <xref linkend="slon"/>, redémarrant le démon à chaque
fois qu'il s'arrête.
</para>
</listitem>
<listitem>
<para>
<filename>tools/altperl/slon_watchdog2</filename> - une version un peu
plus intelligente qui sonde régulièrement la base de donnée, pour
vérifier qu'un événement <command>SYNC</command> s'est produit
récemment. Nous avons connu des connexions VPN qui se terminaient
parfois sans avertir l'application. Dans ce cas, le démon <xref
linkend="slon"/> s'arrête mais ne meurt pas. Ce mécanisme de sondage
résout ce problème.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Le script <filename>slon_watchdog2</filename> est <emphasis>en
général</emphasis> la solution préférable. Il existe un cas où elle n'est
pas souhaitable&nbsp;: lorsqu'on abonne un très gros ensemble qui nécessite
plusieurs heures de <command>COPY SET</command> (le principal événement que
provoque la requête <command>SUBSCRIBE SET</command>). Le problème qui surgit
dans ce cas est que le chien de garde constate qu'aucun événement
<command>SYNC</command> n'a été produit depuis deux heures, et déduit que
quelque chose est cassé, ce qui implique un redémarrage du démon slon, ce qui
relance du coup le <command>COPY SET</command>. Récemment, le script a été
modifié pour détecter les <command>COPY SET</command> en cours d'exécution.
</para>
<para>
Dans &slony1; version 1.2, la structure du démon <application>slon</application>
a été révisée de manière importante pour le rendre moins fragile. Le processus
principal ne s'arrête que si vous envoyez expressément un signal lui demandant
de s'arrêter.
</para>
<para>
Une nouvelle approche est possible dans le script <xref
linkend="launchclusters"/> en utilisant les fichiers de configuration
<application>slon</application> et peut être invoqué comme un service dans
le processus de démarrage du système.
</para>
</sect1>
Jump to Line
Something went wrong with that request. Please try again.