Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
484 lines (433 sloc) 20.1 KB
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<refentry id="slon">
<refmeta>
<refentrytitle id="app-slon-title"><application>slon</application></refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo>Application</refmiscinfo>
</refmeta>
<refnamediv>
<refname><application>slon</application></refname>
<refpurpose>
Le démon &slony1;
</refpurpose>
</refnamediv>
<indexterm zone="slon">
<primary>slon</primary>
</indexterm>
<refsynopsisdiv>
<cmdsynopsis>
<command>slon</command>
<arg rep="repeat"><replaceable class="parameter">option</replaceable></arg>
<arg><replaceable class="parameter">clustername</replaceable></arg>
<arg><replaceable class="parameter">conninfo</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para><application>slon</application> est un démon applicatif qui
<quote>contrôle</quote> la réplication &slony1;. Une
instance <application>slon</application> doit être lancée pour
chaque n&oelig;ud du cluster &slony1;.</para>
</refsect1>
<refsect1 id="r1-app-slon-3">
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>-d</option> <replaceable class="parameter">log_level</replaceable></term>
<listitem>
<para>
Le paramètre <envar>log_level</envar> spécifie le niveau de
messages de débogage que <application>slon</application> doit
afficher dans son journal d'activité.
</para>
<para id="nineloglevels">Il y a neuf niveaux de débogage&nbsp;:
<itemizedlist>
<listitem><para>Fatal</para></listitem>
<listitem><para>Error</para></listitem>
<listitem><para>Warn</para></listitem>
<listitem><para>Config</para></listitem>
<listitem><para>Info</para></listitem>
<listitem><para>Debug1</para></listitem>
<listitem><para>Debug2</para></listitem>
<listitem><para>Debug3</para></listitem>
<listitem><para>Debug4</para></listitem>
</itemizedlist>
</para>
<para>
Les cinq premiers niveaux de débogage (de Fatal à Info) sont
<emphasis>toujours</emphasis> affichés dans les traces. Dans les
premières versions de &slony1;, le niveau des traces
<quote>suggéré</quote> était 2, ce qui affichait tous les messages
jusqu'au niveau Debug2. Avec &slony1; version 2, il est recommandé
de positionner <envar>log_level</envar> à 0&nbsp;; la plupart des
informations intéressantes sont produites à des niveaux supérieurs
à celui-là.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-s</option> <replaceable class="parameter">Intervalle entre
les vérifications SYNC</replaceable></term>
<listitem>
<para>
Le paramètre <envar>sync_interval</envar>, exprimé en millisecondes,
indique à quelle fréquence <application>slon</application> doit
vérifier si un événement <command>SYNC</command> doit être produit.
La valeur par défaut est 2000 ms. La boucle principale dans
<function>sync_Thread_main()</function> est endormie pendant des
intervalles de <envar>sync_interval</envar> millisecondes entre
chaque itération.
</para>
<para>
Un intervalle de vérifications très court garantit que le n&oelig;ud
origine soit <quote>très suivi</quote> car il met à jour les abonnés
plus fréquemment. Si vous avez des séquences répliquées qui sont
souvent mises à jour <emphasis>sans</emphasis> que certaines tables
ne soient affectées, cela évite que des opérations qui mettent à
jour uniquement ces séquences soient effectuées, et ainsi évite la
génération d'événements de synchronisation.
</para>
<para>
Si un n&oelig;ud n'est pas l'origine d'un ensemble de réplication,
et donc qu'il ne reçoit aucune mise à jour des données répliquées,
alors il est un peu inutile de mettre une valeur inférieure à celle
du paramètre <envar>sync_interval_timeout</envar>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-t</option><replaceable class="parameter">intervalle maximal
entre deux SYNC</replaceable></term>
<listitem>
<para>
À la fin de chaque période <envar>sync_interval_timeout</envar>,
un événement <command>SYNC</command> est produit sur le n&oelig;ud
<quote>local</quote> même s'il n'y eu aucune mise à jour des
données répliquées et qu'aucun <command>SYNC</command> n'a été
généré.
</para>
<para>
Si l'activité de l'application s'arrête, soit parce que
l'application a été éteinte, soit parce que les utilisateurs humains
sont rentrés chez eux et arrêtés les mises à jour, alors le démon
&lslon; continue de tourner et se réveille toutes les
<envar>sync_interval</envar> millisecondes, et si aucune mise à
jour ne s'est produite, alors aucun événement <command>SYNC</command>
n'est généré. Sans ce paramètre <quote>timeout</quote>,
<emphasis>aucun</emphasis> événement <command>SYNC</command> ne
pourrait être produit, et cela entraînerait la chute du système de
réplication.
</para>
<para>
Le paramètre <envar>sync_interval_timeout</envar> provoque la
génération de <command>SYNC</command>, même s'il n'y a pas
réellement de travail de réplication a faire. Plus la valeur de
ce paramètre est bas, plus les évènements <command>SYNC</command>
lorsque l'application n'est pas active. Ceci a deux effets&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
Le système aura plus de travail.
</para>
<para>
(Cependant puisque l'application n'utilise pas la base de
données et qu'il n'y a pas de données à répliquer, la charge
de travail supplémentaire sera assez simple à gérer.)
</para>
</listitem>
<listitem>
<para>
La réplication sera tenue un peu plus <quote>à jour</quote>.
</para>
<para>
(Cependant puisqu'il n'y a pas de données à répliquer, être
plus souvent <quote>mis à jour</quote> est un mirage.)
</para>
</listitem>
</itemizedlist>
<para>
La valeur par défaut est 10000 ms et la valeur maximale est 120000
ms. Par défaut, vous pouvez prévoir que chaque n&oelig;ud soit
<quote>synchronisé</quote> par un <command>SYNC</command> toutes les
dix secondes.
</para>
<para>
Notez que des événements <command>SYNC</command> sont aussi générés
sur chaque n&oelig;ud abonné. Cependant, puisqu'ils ne contiennent
pas de données à répliquer par les autres n&oelig;uds, les évènements
<command>SYNC</command> des n&oelig;uds abonnés ne sont pas
terriblement intéressants.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-g</option> <replaceable class="parameter">taille du groupe</replaceable></term>
<listitem>
<para>
L'option <envar>sync_group_maxsize</envar> contrôle la taille
maximale d'un groupe <command>SYNC</command>. La valeur par défaut
est 6. Ainsi, si un n&oelig;ud particulier a 200 événements
<command>SYNC</command> de retard, il essaiera de les regrouper
par groupes dont la taille maximale sera
<envar>sync_group_maxsize</envar>. Ceci doit permettre de réduire
le temps de lantence au démarrage (NdT&nbsp;: «&nbsp;overhead&nbsp;»)
en réduisant le nombre de transactions à <quote>valider</quote>.
</para>
<para>
La valeur par défaut, 6, est probablement adéquate pour les petits
systèmes qui ne peuvent allouer que des quantités limitées de
mémoire à <application>slon</application>. Si vous avez beaucoup de
mémoire, il est raisonnable d'augmenter cette valeur car cela
augmentera la quantité de travail réalisée à chaque transaction, et
cela permettra à un n&oelig;ud abonné de rattraper plus vite son
retard.
</para>
<para>
Les processus Slon sont souvent très petits&nbsp;; même en cas
de valeurs très fortes pour cette option,
<application>slon</application> devrait simplement grossir de
quelques Mo.
</para>
<para>
Le gros avantage d'augmenter ce paramètre est que cela divise
le nombre de transactions <command>COMMIT</command>&nbsp;; passer
de 1 à 2 aura probablement un impact considérable, mais le bénéfice
se réduit progressivement lorsque la taille des groupes est
suffisamment large. Il n'y aura probablement pas de différence
notable entre 80 et 90. Rendu à ce niveau, l'augmentation de cette
valeur dépend du fait que les grands ensembles de <command>SYNC</command>
perturbent les curseurs de <envar>LOG</envar> en consommant de plus
en plus de mémoire et nécessitant plus d'efforts lors des tris.
</para>
<para>
Dans &slony1; version 1.0, <application>slon</application> essaie
toujours de regrouper un maximum de <command>SYNC</command> ensemble,
ce qui <emphasis>n'est pas</emphasis> idéal si la réplication a été
déstabilisée par de grosses mises à jour (<emphasis>par
exemple</emphasis>, une transaction unique qui met à jour des
centaines de milliers de lignes) ou lorsque les
<command>SYNC</command> ont été interrompus sur un n&oelig;ud origine,
ce qui fait que les suivants sont volumineux. Vous rencontrerez ce
problème&nbsp;: en regroupant des <command>SYNC</command> très
larges, le processus <application>slon</application> peut échouer.
Au redémarrage, il essaie à nouveau de traiter ce large ensemble
de <command>SYNC</command> et il retombe sur le même problème
encore et encore jusqu'à ce qu'un administrateur interrompe tout
cela et change la valeur de l'option <option>-g</option> pour
sortir de cette situation d'<quote>inter-blocage</quote>.
</para>
<para>
Au contraire, avec &slony1; 1.1 et les versions ultérieures, le démon
<application>slon</application> s'adapte en augmentant
<quote>progressivement</quote> le nombre de <command>SYNC</command>
par groupe, de 1 jusqu'à la valeur maximale. Ainsi, si quelques
<command>SYNC</command> posent problème, le démon
<application>slon</application> pourra (s'il est surveillé par
un processus chien de garde) traiter un par un ces évènements
<command>SYNC</command> problématiques, et ainsi éviter
l'intervention d'un administrateur.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-o</option> <replaceable class="parameter">temps de
synchronisation souhaité</replaceable></term>
<listitem>
<para>
La période <quote>maximale</quote> pour un groupe de
<command>SYNC</command>.
</para>
<para>
Si la réplication est en retard, le démon slon va progressivement
augmenter le nombre de <command>SYNC</command> groupés ensemble,
dans le but de ne pas dépasser le temps spécifié par
<envar>desired_sync_time</envar> (pour cela, Slon se base sur le
temps pris par le <emphasis>dernier</emphasis> groupe de
<command>SYNC</command>).
</para>
<para>
La valeur par défaut est 60000ms, c'est-à-dire une minute.
</para>
<para>
Ainsi, vous pouvez prévoir (en tout cas espérer&nbsp;!) que vous
aurez un <command>COMMIT</command> environ toutes les minutes.
</para>
<para>
Cela n'est pas <emphasis>complètement</emphasis> prévisible car il
est possible de demander une <emphasis>très grosse mise à
jour</emphasis> qui fera <quote>exploser</quote> la taille du
<command>SYNC</command>. Dans ce cas-là, l'heuristique sera rétablie
pour le <emphasis>prochain</emphasis> groupe.
</para>
<para>
L'effet final est d'améliorer la façon dont
<productname>Slony-I</productname> gère les variations du trafic.
En commençant avec un événement <command>SYNC</command>, puis
en augmentant progressivement, même si certaines variations seront
assez grandes pour provoquer un crash du processus
<productname>PostgreSQL</productname>, <productname>Slony-I</productname>
redémarrera en traitant un seul <command>SYNC</command> à la fois,
afin que poursuivre le processus de réplication autant que possible.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-c</option> <replaceable class="parameter">cycles de nettoyage</replaceable></term>
<listitem>
<para>
La valeur <envar>vac_frequency</envar> indique la fréquence des
opérations <command>VACUUM</command> lors des cycles de nettoyage.
</para>
<para>
Positionnez cette valeur à zéro pour désactiver les nettoyages
initiés par <application>slon</application>. Si vous utilisez un
mécanisme tel que <application>pg_autovacuum</application> pour
lancer les VACUUM, vous n'aurez probablement pas besoin que slon
initie des VACUUM de lui-même. Sinon, il existe des tables
utilisées par <productname>Slony-I</productname> qui collectent
<emphasis>beaucoup</emphasis> de lignes mortes et qui doivent
être nettoyées fréquemment, en particulier &pglistener;.
</para>
<para>
À partir de &slony1; version 1.1, cela change un peu&nbsp;; le
processus de nettoyage cherche, d'itération en itération,
l'identifiant de la plus ancienne transaction encore active dans
le système. Si l'identifiant ne change pas entre deux itérations,
alors il existe une vieille transaction en activité, et donc un
<command>VACUUM</command> n'apportera rien de bon. À la place, le
processus de nettoyage déclenche simplement une opération
<command>ANALYZE</command> sur ces tables afin de mettre à jours
les statistiques dans <envar>pg_statistics</envar>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-p</option> <replaceable class="parameter">fichier du PID</replaceable></term>
<listitem>
<para>
La variable <envar>pid_file</envar> contient le nom du fichier dans
lequel le PID (identifiant du processus) du démon
<application>slon</application> est stocké.
</para>
<para>
Cela simplifie la création de scripts de surveillance des processus
<application>slon</application> qui s'exécutent sur un hôte.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-f</option> <replaceable class="parameter">fichier de configuration</replaceable></term>
<listitem>
<para>
Fichier qui contient la configuration <application>slon</application>.
</para>
<para>
La configuration est détaillée plus loin dans le chapitre <link
linkend="runtime-config">Configuration de Slon</link>. Si vous avez
défini un ensemble complexe de paramètre ou si vous ne voulez pas
que les paramètres soient visibles dans les variables d'environnement
(notamment les mots de passe), il est plus pratique de placer une
partie, voire l'ensemble des paramètres dans un fichier de
configuration. Vous pouvez également placer les paramètres communs à
tous les processus slon dans un fichier de configuration partagé et
définir en ligne de commande d'autres paramètres que les informations
de connexions. Vous pouvez aussi créer un fichier de configuration
pour chaque n&oelig;ud.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-a</option> <replaceable class="parameter">répertoire des archives</replaceable></term>
<listitem>
<para>
L'option <envar>archive_dir</envar> indique le dossier dans lequel
on place la séquence de fichiers archives contenant les événements
<command>SYNC</command> utilisés en mode &logshiplink;.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-x</option> <replaceable class="parameter">commande à
appliquer pour l'archivage des journaux</replaceable></term>
<listitem>
<para>
Le paramètre <envar>command_on_logarchive</envar> indique la commande
qui doit être exécutée à chaque fois qu'un fichier SYNC est
correctement généré.
</para>
<para>
Voir le chapitre <xref linkend="slon-config-command-on-logarchive"/>
pour plus de détails.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-q</option> <replaceable class="parameter">quitter en
fonction d'un fournisseur</replaceable></term>
<listitem>
<para>
L'option <envar>quit_sync_provider</envar> indique quel processus
fournisseur doit être surveilleé afin d'arrêter la réplication
après un événement donné. Ceci doit être utilisé conjointement avec
l'option <option>-r</option> ci-dessous...
</para>
<para>
Cela permet de stopper la réplication sur un processus
<application>slon</application> après un certain point.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-r</option> <replaceable class="parameter">quitte après
un numéro d'événement</replaceable></term>
<listitem>
<para>
Le paramètre <envar>quit_sync_finalsync</envar> indique le numéro
de l'événement après lequel un processus de réplication doit se
terminer. Ceci doit être utilisé conjointement avec l'option
<option>-q</option> ci-dessus...</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-l</option> <replaceable class="parameter"> interval de retard</replaceable></term>
<listitem>
<para>
L'option <envar>lag_interval</envar> spécifie une valeur temporelle
(en anglais) telle que <command>3 minutes</command>, <command>4
hours</command> ou <command>2 days</command> qui indique le temps
de retard que doit avoir un n&oelig;ud par rapport à son fournisseur.
Cela implique que les événements seront ignorés tant que leur âge
sera inférieur à cet intervalle.
</para>
<warning>
<para>
Il y a un effet secondaire à ce retard&nbsp;; Les événements qui
demandent que tous les n&oelig;uds se synchronisent, notamment
ceux qui sont produits lors d'une opération <xref
linkend="stmtfailover"/> et d'un <xref linkend="stmtmoveset"/>,
devront attendre pendant cet interval de temps.
</para>
<para>
C'est un comportement qui n'est pas idéal dans le cas d'une bascule
après une panne, ou lorsque l'on veut exécuter des scripts DDL
(<xref linkend="stmtddlscript"/> ).
</para>
</warning>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Valeur de retour</title>
<para>
<application>slon</application> renvoie 0 dans le shell s'il s'est terminé
normalement. En cas d'erreur fatale, il exécute la fonction
<function>exit(-1)</function> (qui envoie en général une valeur de retour
de 127 ou 255, suivant votre système d'exploitation).
</para>
</refsect1>
</refentry>