root/traduc/trunk/slony/maintenance.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- DerniÚre modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->

<sect1 id="maintenance"> <title>Maintenance</title>

<indexterm><primary>maintenir &slony1;</primary></indexterm>

<para>&slony1; effectue une grande partie de sa maintenance
de lui-même, dans un processus de <quote>
nettoyage</quote> qui  :

<itemizedlist>

<listitem><para>supprime les anciennes donnéessur
les différentes tables d'espace de nom de
du cluster <productname>Slony-I</productname>,
notamment <xref linkend="table.sl-log-1"/>, <xref
linkend="table.sl-log-2"/>, and <xref
linkend="table.sl-seqlog"/>;</para></listitem>

<listitem><para>effectue un vacuum sur certaines
tables utilisées par &slony1;.
A partir de la version 1.0.5, ceci inclut &pglistener;;
dans les versions antérieures, vous devez lancer
souvent des vacuums sur cette table, sinon
vous verrez votre réplication ralentir
car &slony1; lÚve beaucoup d'événets,
qui mÚnent à table à contenir de nombreux
tuples morts.
</para>

<para>Avec certaines versions (la 1.1; peut-être la 1.0.5)
il est possible de ne plus s'embarrasser avec les vacuums
sur ces tables si vous utiliser quelque chose comme
<application>pg_autovacuum</application>
pour gérer le nettoyage de ces tables.
Malheureusement, il est possible que
<application>pg_autovacuum</application> 
ne nettoie pas assez fréquemment, vous pourrez donc préférer utiliser les vacuums internes.

Nettoyer la table &pglistener; <quote>trop 
souvent</quote>
est moins risqué que de ne pas la nettoyer assez.
</para>

<para>Malheureusement, si vous avez de longues transactions,
les vacuums ne peuvent pas nettoyer les tuples morts 
qui sont plus récents que les anciennes transactions 
toujours en cours. Ceci conduira en particulier à une 
forte croissance de &pglistener; 
et ralentira la réplication.
</para></listitem>


<listitem> <para> Le bug <link linkend="dupkey"> Violation par 
clef dupliqué</link> a permis d'isoler des situations de 
concurrence dans &postgres;
Des problÚms subsiste notamment 
lorsque <command>VACUUM</command> ne 
réclame pas correctement l'espace 
menant à une corruption des arbres B. </para>

<para>Il peut être utile de lancer la commande
<command> REINDEX TABLE sl_log_1;</command>
périodiquement pour éviter ce problÚm
</para> </listitem>

<listitem><para> A partir de la version 1.2,
 la fonctionnalité <quote>log switching</quote>
est arrivée;de temps en temps, elle tente d'interchanger
les données entre &sllog1; and &sllog2; 
afin de réaliser un 
<command>TRUNCATE</command> sur les <quote>plus vielles</quote> 
données.</para>

<para> Cela signifie que de maniÚre réguliÚre,
ces tables sont complÚtement nettoyées ce qui
évitequ'elle ne grossisse trop 
lors d'une charge importante 
et qu'elles deviennent
impossible à nettoyer.

</para> </listitem>

</itemizedlist>
</para>


<sect2 id="maintenance-autovac"> 
<title> Intéraction avec l'autovaccum de &postgres;
</title>

<indexterm><primary>interaction avec autovacuum</primary></indexterm>

<para>Les versions récentes de&postgres; propose
un processus <quote>autovacuum</quote> 
qui détecte les modifications sur les tables et la
création
de tuples mort, puis nettoie de ces tables, 
<quote>Ã  la demande.</quote>.
On a constaté que cela peut interagir de maniÚre
négative avec la politique de vacuum de &slony1;
sur ces propres tables. </para>

<para> &slony1; demande des vacuums sur ses tables
immédiatement aprÚs avoir complété les
transactions
qui sont sensées supprimer de vieilles données,
ce qui est considéré comme le meilleur moment 
pour le faire. Il semble que l'autovacuum détecte 
les changements un peu trop tÃŽt, et lance un vacuum
alors que les transactions ne sont pas complétées,
ce qui est relativement inutile.
Il apparait préférable de configurer l'autovacuum
pour éviter les tables de configuration
gérées par &slony1;. </para>

<para> La requête suivante identifie les tables que 
l'autovacuum ne doit pas traiter (remplacez le nom du
cluster par celui de votre configuration locale) :
</para>

<programlisting>
moncluster=# select oid, relname from pg_class where relnamespace = (select oid from pg_namespace where nspname = '_' || 'monCluster') and relhasindex;
  oid  |   relname    
-------+--------------
 17946 | sl_nodelock
 17963 | sl_setsync
 17994 | sl_trigger
 17980 | sl_table
 18003 | sl_sequence
 17937 | sl_node
 18034 | sl_listen
 18017 | sl_path
 18048 | sl_subscribe
 17951 | sl_set
 18062 | sl_event
 18069 | sl_confirm
 18074 | sl_seqlog
 18078 | sl_log_1
 18085 | sl_log_2
(15 rows)
</programlisting>

<para>La requête suivante remplira la table 
<envar>pg_catalog.pg_autovacuum</envar> 
avec les informations de configuration adéquates :
<command> insert into pg_catalog.pg_autovacuum (vacrelid,
enabled) select oid, 'f' from pg_catalog.pg_class where relnamespace =
(select oid from pg_namespace where nspname = '_' || 'monCluster') and
relhasindex; </command> </para>
</sect2>

<sect2><title> Chiens de garde : garder les Slons en vie</title>

<indexterm><primary>Chiens de garde pour garder en vie les démons slon 
</primary></indexterm>

<para>Il y a deux scripts <quote>chiens de garde</quote> disponibles pour surveiller
  la réplication et relancer les processus <application>slon</application>
  lorsqu'il meurent pour telle ou telle raison, par exemple une   
<quote>coupure</quote> réseau qui provoque une perte de connectivité.</para>

<para>Ils pourraient vous être utiles...</para>

<para> La <quote>meilleur et nouvelle</quote> façon de gérer les processus <xref
linkend="slon"/> se fait via une combinaison de  <xref
linkend="mkslonconf"/>, qui crée un fichier de configuration pour chaque noeud
  d'un cluster, et <xref linkend="launchclusters"/> qui utilise ces fichiers 
  de configuration.</para>

<para> Cette approche est préférable aux anciens systÚmes de 
  <quote>chiens de garde</quote> car vous pouvez <quote>pointer</quote>
  précisément, dans chaque fichier de configurationn, le paramÚtrage 
  désiré pour chaque noeud, sans avoir à vous préoccuper des options
  que le script chien de garde vous proposer ( ou pas ). Ceci est particuliÚrement
  important si vous utilisez le <link linkend="logshipping"> log shipping </link>, 
  auquel cas oublier l'option <command>-a</command> peut ruiner le noeud 
  destinataire du log shipping et ruiner par là -même votre journée.</para>

</sect2>

<sect2 id="gensync"><title>En parallÚle aux chiens de garde : generate_syncs.sh</title>

<indexterm><primary>Génére des SYNCs</primary></indexterm>

<para>Un nouveau script est apparu dans &slony1; 1.1, il s'agit de 
<application>generate_syncs.sh</application>, qui est utilise dans les situations
suivantes.</para>

<para>Supposons que vous avez un serveur non fiable sur lequel le démon 
<application>slon</application> daemon ne fonctionne pas en continu,
en rentrant de week-end vous vous trouverez peut-êtrÚs la situation suivante :
</para>

<para>Le vendredi soir, quelque chose s'est <quote>cassé</quote> et le temps 
  que la base de donnée redémarre, aucun des démons <application>slon</application>
  n'a survécu. Votre application en ligne a ensuite connu trois jours 
  de charge transactionnelle relativement forte.
  </para>

<para>Lorsque vous redémarrez <application>slon</application> le lundi, il n'y a pas eu 
  de synchronisation sur le maître depuis Vendredi, ce qui fait que le prochain 
<quote>ensemble de SYNC</quote> comprendra toutes les modifications entre vendredi 
et lundi. Aïe !</para>

<para>Si vous lancez <application>generate_syncs.sh</application> via une tache cron
  toute les 20 minutes, cela créera de force des événements <command>SYNC</command>
  sur l'origine, ce qui implique qu'entre vendredi et lundi, les nombreuses mises à jour
  seront découpées en plus de 100 ensemble de SYNCs, qui pourront être appliqués de 
  maniÚre incrémentale, rendant la restauration mois déplaisante.
</para>

<para>Notez que si les <command>SYNC</command>s <emphasis>sont</emphasis> exécutés 
  réguliÚrement, ce scripts ne fera rien de particulier.</para>
</sect2>

<sect2><title>Tester l'état &slony1; </title>

<indexterm><primary>tester le statut du cluster</primary></indexterm>

<para> Dans le répertoire <filename>tools</filename>, vous trouverez
  des scripts nommés <filename>test_slony_state.pl</filename> et
<filename>test_slony_state-dbi.pl</filename>.  Le premier utilise l'interface Perl/DBI
; l'autre utilise l'interface Pg.
</para>

<para> Les deux font essentiellement la même chose, c'est à dire
  se connecter à un noeud &slony1; (celui de votre choix) et à partir de là 
  détermine la liste des noeuds du cluster. Ensuite ils lancent une
  série de requêtes ( en lecture seule, et donc sans danger ) afin 
  de parcourir différentes tables à la recherche de différentes conditions
  susceptibles de rélever des problÚmes, telles que :
</para>

<itemizedlist>
<listitem><para> Gonflement des tables comme pg_listener, sl_log_1, sl_log_2, sl_seqlog; </para></listitem>
<listitem><para> Voies d'écoute;</para></listitem>
<listitem><para> Analyse de la propagation des événéments; </para></listitem>
<listitem><para> Analyse de la propagation des confirmations. </para> 

<para> Si la communication est <emphasis>légÚrement</emphasis> perturbée,
la réplication peut fonctionner, mais les confirmations peuvent ne pas être retournées,
ce qui empêche les noeuds de nettoyer les vieux événements et les anciennes données de réplication
. </para> </listitem>
</itemizedlist>

<para> Lancer ce script une par heure ou une fois par jour peut vous aider
  à détecter les symptomes précurseurs de certains problÚmes, avant même
  que cela conduise à une dégradation des performances. </para>
</sect2>

<sect2><title>Scripts de test de la réplication</title>

<para>Dans le répertoire <filename>tools</filename> on peut trouver 4
  scripts qui peuvent être utilisés pour surveiller des instances &slony1; :

<itemizedlist>

<listitem><para> <command>test_slony_replication</command> est un script 
    Perl auquel vous pouvez passer les informations de connexion
    d'un noeud &slony1;.  Il test alors la table  <xref linkend="table.sl-path"/>
    et d'autres informations sur ce noeud afin de déterminer la forme de
    l'ensemble de réplication choisi.</para>

<para> Ensuite il injecte des requêtes de test dans la table nommée
<envar>slony_test</envar> qui est définie comme ci-dessous, et
qui doit être ajoutée à l'ensemble des tables répliquées :

<programlisting>
CREATE TABLE slony_test (
    description text,
    mod_date timestamp with time zone,
    "_Slony-I_testcluster_rowID" bigint DEFAULT nextval('"_testcluster".sl_rowid_seq'::text) NOT NULL
);
</programlisting></para>

<para> La derniÚre colonne de la table est définie par &slony1; comme
  une une clé primaire manquante...</para>

<para> Ce script génÚre une ligne de sortie pour chaque noeud &slony1; actif
  pour l'ensemble de réplication défini dans un fichier nommé 
  <filename>cluster.fact.log</filename>.</para>

<para> Il y a une option additionelle, <option>finalquery</option>, qui vous permet de
  passer une requête SQL spécifique à votre application pour déterminer
 l'état de votre application.</para></listitem>

<listitem><para><command>log.pm</command> est un module Perl module qui gÚre les logs des 
    scripts Perl.</para></listitem>

<listitem><para><command>run_rep_tests.sh</command> est un script <quote>wrapper</quote>
    qui lance <command>test_slony_replication</command>.</para>

<para> Si vous avez plusieurs clusters &slony1;, vous pouvez placer dans 
  ce fichier le configuration pour se connecter à tous ces 
clusters.</para></listitem>

<listitem><para><command>nagios_slony_test</command> est un script qui
    a été construit pour interroger les fichiers logs afin de pouvoir
    lancer le test de réplication réguliÚrement ( nous le laissons 
    toutes les 6 minutes) et qu'un outil de supervision tel que 
 <ulink
url="http://www.nagios.org/"> <productname>Nagios</productname>
</ulink> puisse utiliser le script to surveiller l'état indiqué 
dans ces logs.</para>

<para> Il semble plus efficace qu'une tache
<application>cron</application> lance les tests et que 
<productname>Nagios</productname> vérifie le résultat plutÎt que
de voir <productname>Nagios</productname> lancer directement 
les tests.  Ces tests peuvent vérifier l'ensemble du cluster &slony1;
d'un seul coup, plutot que de voir <productname>Nagios</productname> 
provoque des mises à jour en permanence.</para></listitem>

</itemizedlist></para>
</sect2>

<sect2><title> Autres tests de réplication</title>

<indexterm><primary>tester la réplication</primary></indexterm>  
  
<para> La méthodologie de la section précédente est conçu avec un vue
  pour minimiser le coût des requêtes de test; sur un cluster trÚs chargé,
  supportant des centaines d'utilisateurs, le coût associé aux quelques
  requêtes de test n'est un point important et le temps de configuration
  des tables et des injecteurs de données est trÚs élevé.</para>

<para> 3 autres méthodes pour analyser l'état de la réplication sont 
apparus :</para>

<itemizedlist>

<listitem><para> Pour un test orienté sur l'application, il est utile 
    de créer une vue sur une table fréquemment mise à jour pour remonter
    des informations spécifique à l'application.</para>

<para> Par exemple, on peut chercher soit des statistiques
  sur les objets applicatif les plus récents, soit les transactions 
  de l'applicatio. Par exemple :</para>

<para> <command> create view replication_test as select now() -
txn_time as age, object_name from transaction_table order by txn_time
desc limit 1; </command> </para>

<para> <command> create view replication_test as select now() -
created_on as age, object_name from object_table order by id desc
limit 1; </command> </para>

<para> Il y a un inconvénient : Cette approche nécessite que vous 
  ayez une activité constante sur le systÚme impliquant la création
  de nouvelles transactions de maniÚre réguliÚre.
  Si quelque chose ne fonctionne pas dans votre application. vous obtiendrez 
  des fausses alertes en provenance de la réplication, alors même que la réplication
  fonctionne correctement.</para>

</listitem>

<listitem><para> La vue  &slony1; nommée <envar>sl_status</envar>
    fournit des informations sur la synchronisation des différents noeuds.
    Son contenu n'est intéressant que sur les noeuds origine, car les
    événements générés sur les autres noeuds peuvent généralement
    être ignorés. </para>
</listitem>

<listitem><para> Voir également la discussion sur <xref linkend="slonymrtg"/>. </para></listitem>

</itemizedlist>
</sect2>
<sect2><title> Fichiers de log</title>

<indexterm><primary>fichiers de log</primary></indexterm>

<para>Les démons <xref linkend="slon"/> génÚre des fichiers de logs plus 
  ou moins verbeux, selon le niveau de debug activé. Dans ce cas vous pouvez :

<itemizedlist>

<listitem><para> Utiliser un programme de rotations de logs comme
<application>rotatelogs</application> d'<productname>Apache</productname>
 pour avoir une sécancer de fichiers de logs et évite d'avoir des fichiers
trop gros;</para></listitem>

<listitem><para> Purgez réguliÚrement les vieux fichiers de log.</para></listitem>

</itemizedlist>
</para>
</sect2>

<sect2><title>service </title>
<indexterm><primary>service pour BSD </primary></indexterm>

<sect3><title>slon</title>

<para> Ce script crée un répertoire pour le service slon qui pourra être 
  utilisé avec la commande svscan de daemontools. Ce script utilise multilog 
  de maniÚre trÚs basique, ce qui semble être standard pour les installations
  daemontools / multilog. Si vous souhaitez une gestion intelligente des logs,
  consultez la section logrep ci-dessous. Actuellement ce script à des possibilités
  de gestion d'erreurs trÚs limitées.
  </para>

<para> Pour les usages non-interactifs, configurer les variables d'environnement
  suivantes :  <envar>BASEDIR</envar> <envar>SYSUSR</envar>
<envar>PASSFILE</envar> <envar>DBUSER</envar> <envar>HOST</envar>
<envar>PORT</envar> <envar>DATABASE</envar> <envar>CLUSTER</envar>
<envar>SLON_BINARY</envar> Si un seul de ces valeurs n'est pas définie, 
le script demande les informations de maniÚre interactive.</para>

<itemizedlist>
<listitem><para>
<envar>BASEDIR</envar> l'emplacement où la structure du répertoire du service slon sera créée.
Il ne faut <emphasis>pas</emphasis> que ce soit le répertoire <filename>/var/service</filename>;</para></listitem>
<listitem><para>
<envar>SYSUSR</envar> l'utilisateur unix qui lancera le processus slon (et multilog);</para></listitem>
<listitem><para>
<envar>PASSFILE</envar> l'emplacement du fichier <filename>.pgpass</filename>. (par défaut <filename>~sysusr/.pgpass</filename>);</para></listitem>
<listitem><para>
<envar>DBUSER</envar> L'utilisateur postgres que slon doit utiliser ( par défaut slony);</para></listitem>
<listitem><para>
<envar>HOST</envar> l'adresse du serveur ou le slon doit se connecter (par défaut localhost)</para></listitem>
<listitem><para>
<envar>PORT</envar> le port de connexion (par défaut 5432)</para></listitem>
<listitem><para>
<envar>DATABASE</envar> la base de données sur laquelle slon se connecte (par défaut dbuser)</para></listitem>
<listitem><para>
<envar>CLUSTER</envar> le nom du cluster Slony1 (par défaut database)</para></listitem>
<listitem><para>
<envar>SLON_BINARY</envar> le chemin complet vers le binaire slon (par défaut <command>which slon</command>)</para></listitem>
</itemizedlist>
</sect3>
<sect3><title>logrep-mkservice.sh</title>

<para>Ce script utilise <command>tail -F</command> pour extraire des données des fichiers
  de logs en vous permettant d'utiliser des filtres multilog (via l'option CRITERIA) afin
  de créer des fichiers de logs spécifiques. Le but est de fournir un moyen de surveiller
  les fichiers de logs en temps réel en quête de données  <quote>intéressante</quote>
  sans devoir modifier le fichier de log initial ou gacher des ressources CPU/IO 
  en re-scannant les logs réguliÚrement.
</para>

<para>Pour une utilisation non interactive, il faut configurer les variable:
  <envar>BASEDIR</envar> <envar>SYSUSR</envar> <envar>SOURCE</envar>
<envar>EXTENSION</envar> <envar>CRITERIA</envar>. Si une seul de ces options n'est 
pas définie le script demande interactivement les informations de configuration.
</para>

<itemizedlist>
<listitem><para>
<envar>BASEDIR</envar> : l'emplacement où sera créée la structure du répertoire du service de logrep.
Il ne faut <emphasis>pas</emphasis> que ce soit le répertoire <filename>/var/service</filename>.
</para></listitem>
<listitem><para><envar>SYSUSR</envar> : l'utilisateur unix qui lancera le service.</para></listitem>
<listitem><para><envar>SOURCE</envar> : nom du service de log que vous voulez suivre.</para></listitem>
<listitem><para><envar>EXTENSION</envar> : un tag pour différencier ce logrep de ceux qui utilisent la même source.</para></listitem>
<listitem><para><envar>CRITERIA</envar> : le filtre multilog que vous voulez utiliser.</para></listitem>
</itemizedlist>

<para> Un exemple trivial consiste à produire un fichier de log de tous les messages d'erreur
  slon qui pourrait être utilisé pour déclencher une alerte nagios :
  <command>EXTENSION='ERRORS'</command>
<command>CRITERIA="'-*' '+* * ERROR*'"</command>
(On relance la surveillance en déclenchant une rotation des logs avec <command>svc -a $svc_dir</command>)
</para>

<para> Une application plus intéressante est la surveillance de la progression d'une souscription d'un noeud :
<command>EXTENSION='COPY'</command>
<command>CRITERIA="'-*' '+* * ERROR*' '+* * WARN*' '+* * CONFIG enableSubscription*' '+* * DEBUG2 remoteWorkerThread_* prepare to copy table*' '+* * DEBUG2 remoteWorkerThread_* all tables for set * found on subscriber*' '+* * DEBUG2 remoteWorkerThread_* copy*' '+* * DEBUG2 remoteWorkerThread_* Begin COPY of table*' '+* * DEBUG2 remoteWorkerThread_* * bytes copied for table*' '+* * DEBUG2 remoteWorkerThread_* * seconds to*' '+* * DEBUG2 remoteWorkerThread_* set last_value of sequence*' '+* * DEBUG2 remoteWorkerThread_* copy_set*'"</command>
</para>

<para>Si vous avez un log de suscription, alors il est facile
  de déterminer si un noeud donné est en train de réaliser une copie 
  ou une autre activité de souscription. Si les log ne sont pas vide et 
  ne se termine pas par  
<command>"CONFIG enableSubscription: sub_set:1"</command>
(ou 1 est le numéro d'ensemble de réplication que vous avez abonné)
alors le slon est au milieu d'une copie initiale.</para>

<para> Si vous surveiller le mtime du fichier de log de votre noeud primaire
  pour déterminer si le slon est tombé dans le coma, vérifier ce log de souscription 
  est un bon moyen d'éviter de stopper le noeud alors qu'un souscription est en cours.
  En bonus, puisque les slons utilise svscan, vous pouvez simplement détruire le fichier
  ( via l'interface svc ) et laisser svscan le recommencer plus tard. J'ai également 
  découvert que les logs de COPY sont pratiques pour suivre de maniÚre interactive
  l'activité des souscritpions.
  </para>
</sect3>

</sect2>
</sect1>