3. Les démons Slon
Les programmes qui effectuent concrètement la réplication Slony-I™ sont les démons slon.
Vous devez lancer une instance slon(1) sur chaque nœud du cluster Slony-I™, que ce nœ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œ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 MOVE SET ou FAILOVER peut modifier le rôle des nœuds, slon doit fonctionner pour tous les nœ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 :
-
Chaque démon slon doit être capable de communiquer rapidement avec la base de données dont il est le « contrôleur ». Ainsi, si un cluster Slony-I™ 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œud impliquera que le démon slon effectuera une réplication un peu moins rapide.
-
Les meilleurs résultats sont obtenus en exécutant chaque démon slon 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.
-
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 slon.
![[Avertissement]](images/warning.png)
Avertissement
Ne lancez pas un démon slon devant gérer un nœud à travers un lien WAN, si possible. Tout problème avec ce lien peut tuer les connexions et ainsi laisser des connexions « zombies » sur les nœ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 FAQ au sein de la section sur les connexions slon multiples.
Historiquement, les processus slon ont été plutôt fragiles, défaillant dès qu'ils rencontraient une erreur significative. Ce comportement impliquait l'utilisation de « chiens de garde » qui surveillent les démons afin de s'assurer que, si un slon s'arrête, il soit remplacé par un autre.
Il existe deux scripts de « chiens de garde » actuellement disponible dans l'arborescence des sources de Slony-I™ :
-
tools/altperl/slon_watchdog - une version « précoce » qui contient basiquement une boucle autour de l'invocation de slon(1), redémarrant le démon à chaque fois qu'il s'arrête.
-
tools/altperl/slon_watchdog2 - une version un peu plus intelligente qui sonde régulièrement la base de donnée, pour vérifier qu'un événement SYNC 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 slon(1) s'arrête mais ne meurt pas. Ce mécanisme de sondage résout ce problème.
Le script slon_watchdog2 est en général la solution préférable. Il existe un cas où elle n'est pas souhaitable : lorsqu'on abonne un très gros ensemble qui nécessite plusieurs heures de COPY SET (le principal événement que provoque la requête SUBSCRIBE SET). Le problème qui surgit dans ce cas est que le chien de garde constate qu'aucun événement SYNC 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 COPY SET. Récemment, le script a été modifié pour détecter les COPY SET en cours d'exécution.
Dans Slony-I™ version 1.2, la structure du démon slon 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.
Une nouvelle approche est possible dans le script Section 21.4, « launch_clusters.sh » en utilisant les fichiers de configuration slon et peut être invoqué comme un service dans le processus de démarrage du système.
slonik
