[Trad] [svn:pgfr] r1240 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Mar 17 Fév 00:34:32 CET 2009
Author: gleu
Date: 2009-02-17 00:34:31 +0100 (Tue, 17 Feb 2009)
New Revision: 1240
Modified:
traduc/trunk/slony/maintenance.xml
Log:
Relecture, ?\195?\169tape 6 (?).
Modified: traduc/trunk/slony/maintenance.xml
===================================================================
--- traduc/trunk/slony/maintenance.xml 2009-02-11 22:07:11 UTC (rev 1239)
+++ traduc/trunk/slony/maintenance.xml 2009-02-16 23:34:31 UTC (rev 1240)
@@ -4,123 +4,111 @@
par $Author$
révision $Revision$ -->
-<sect1 id="maintenance"> <title>Maintenance</title>
-
+<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 :
+<para>
+ &slony1; effectue une grande partie de sa maintenance lui-même, dans un
+ processus de <quote>nettoyage</quote> qui :
-<itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>
+ supprime les anciennes données sur les différentes tables du schéma
+ de <productname>Slony-I</productname>, notamment <xref
+ linkend="table.sl-log-1"/>, <xref linkend="table.sl-log-2"/> et <xref
+ linkend="table.sl-seqlog"/> ;
+ </para>
+ </listitem>
-<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;. À
+ partir de la version 1.0.5, ceci inclut &pglistener; ; dans les
+ versions antérieures, vous devez lancer souvent des VACUUM sur cette
+ table, sinon vous verrez votre réplication ralentir car &slony1; lève
+ beaucoup d'événements, qui mènent à ce que la table contienne de
+ nombreuses lignes mortes.
+ </para>
-<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 VACUUM sur ces tables si vous
+ utilisez 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 VACUUM internes.
+ Nettoyer la table &pglistener; <quote>trop souvent</quote> est moins
+ risqué que de ne pas la nettoyer assez.
+ </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.
+ <para>
+ Malheureusement, si vous avez de longues transactions, les VACUUM ne
+ peuvent pas nettoyer les lignes mortes qui sont plus récentes que les
+ anciennes transactions toujours en cours. Ceci conduira en particulier
+ à une forte croissance de &pglistener; et ralentira la réplication.
+ </para>
+ </listitem>
-Nettoyer la table &pglistener; <quote>trop
-souvent</quote>
-est moins risqué que de ne pas la nettoyer assez.
-</para>
+ <listitem>
+ <para>
+ Le bogue <link linkend="dupkey">violation par clef dupliquée</link> a
+ permis d'isoler des situations de concurrence dans &postgres;. Des
+ problèmes subsistent notamment lorsque <command>VACUUM</command> ne
+ réclame pas correctement l'espace menant à une corruption des index de
+ type B-tree.
+ </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>
+ <para>
+ Il peut être utile de lancer la commande <command>REINDEX TABLE
+ sl_log_1;</command> périodiquement pour éviter ce problème.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ À 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; et &sllog2; afin de réaliser
+ un <command>TRUNCATE</command> sur les <quote>plus vieilles</quote>
+ données.
+ </para>
-<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>
+ Cela signifie que, de manière régulière, ces tables sont complètement
+ nettoyées ce qui évite qu'elles ne grossissent trop lors d'une charge
+ importante et qu'elles deviennent impossibles à nettoyer.
+ </para>
+ </listitem>
+ </itemizedlist>
</para>
-
<sect2 id="maintenance-autovac">
-<title> Intéraction avec l'autovaccum de &postgres;
-</title>
-
+<title>Interaction avec l'autovacuum 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>
+ Les versions récentes de&postgres; proposent un processus
+ <quote>autovacuum</quote> qui détecte les modifications sur les tables et
+ la création de lignes mortes, puis nettoie 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>
+ &slony1; demande des VACUUM 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 terminées, ce qui est relativement inutile. Il
+ apparaît 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>
+ 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>
@@ -145,349 +133,530 @@
(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>
+<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>
+<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>
-<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
+<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>
+ lorsqu'ils 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>
+ 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>
+ La <quote>meilleure 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 nœud 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>
+<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 nœud, sans
+ avoir à vous préoccuper des options que le script chien de garde vous propose
+ (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 nœud 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>
+<sect2 id="gensync"><title>En parallèle aux chiens de garde :
+generate_syncs.sh</title>
+<indexterm><primary>générer des SYNC</primary></indexterm>
-<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>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>
+ Supposons que vous avez un serveur non fiable sur lequel le démon
+ <application>slon</application> ne fonctionne pas en continu, en rentrant de
+ week-end vous vous trouverez peut-être 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
+<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>
-<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>
+ 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>
+ 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 ensembles
+ de SYNC, qui pourront être appliqués de manière incrémentale, rendant la
+ restauration moins 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>
+<para>
+ Notez que si les <command>SYNC</command> <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>
-
+<sect2><title>Tester l'état de &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>
+ 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 PostgreSQL.
</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>
+ Les deux font essentiellement la même chose, c'est-à-dire se connecter à un
+ nœud &slony1; (celui de votre choix) et, à partir de là, détermine la
+ liste des nœuds du cluster. Ensuite ils lancent une série de requêtes
+ (en lecture seule, donc sans danger) afin de parcourir différentes tables à
+ la recherche de différentes conditions susceptibles de revéler 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>
+ <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énements ;
+ </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>
+ <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 nœuds 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>
+<para>
+ Lancer ce script une fois 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; :
+<para>
+ Dans le répertoire <filename>tools</filename>, on peut trouver quatre scripts
+ qui peuvent être utilisés pour surveiller des instances &slony1; :
-<itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <command>test_slony_replication</command> est un script Perl auquel
+ vous pouvez passer les informations de connexion d'un nœud
+ &slony1;. Il teste alors la table <xref linkend="table.sl-path"/> et
+ d'autres informations sur ce nœud afin de déterminer la forme de
+ l'ensemble de réplication choisi.
+ </para>
-<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 :
-<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 (
+ <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>
+);</programlisting>
+ </para>
-<para> La dernière colonne de la table est définie par &slony1; comme
- une une clé primaire manquante...</para>
+ <para>
+ La dernière colonne de la table est définie par &slony1; comme 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>
+ Ce script génère une ligne de sortie pour chaque nœud &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>
+ <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>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>
+ <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>
+ <para>
+ Si vous avez plusieurs clusters &slony1;, vous pouvez placer dans ce
+ fichier la 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>
+ <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 six minutes) et
+ qu'un outil de supervision tel que <ulink
+ url="http://www.nagios.org/"> <productname>Nagios</productname></ulink>
+ puisse utiliser le script pour 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>
+ <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>
+ provoquer des mises à jour en permanence.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
-</itemizedlist></para>
</sect2>
-<sect2><title> Autres tests de réplication</title>
-
+<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>
+<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 tests ; sur un cluster très chargé, supportant
+ des centaines d'utilisateurs, le coût associé aux quelques requêtes de test
+ n'est pas un point important et le temps de configuration des tables et des
+ injecteurs de données est très élevé.
+</para>
+<para>
+ Trois autres méthodes sont apparus pour analyser l'état de la
+ réplication :
+</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écifiques à l'application.
+ </para>
-<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
+ applicatifs les plus récents, soit les transactions de l'application.
+ Par exemple :
+ </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() -
-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> <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>
-<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>
+ <para>
+ La vue &slony1; nommée <envar>sl_status</envar> fournit des informations
+ sur la synchronisation des différents nœuds. Son contenu n'est
+ intéressant que sur les nœuds origine car les événements générés
+ sur les autres nœuds peuvent généralement être ignorés.
+ </para>
+ </listitem>
-</listitem>
+ <listitem>
+ <para>
+ Voir également la discussion sur <xref linkend="slonymrtg"/>.
+ </para>
+ </listitem>
+</itemizedlist>
-<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>
+<sect2><title>Journaux applicatifs</title>
+<indexterm><primary>journaux applicatifs</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 :
+<para>
+ Les démons <xref linkend="slon"/> génère des journaux applicatifs plus ou
+ moins verbeux, selon le niveau de débogage activé. Dans ce cas, vous
+ pouvez :
-<itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Utiliser un programme de rotation des journaux applicatifs comme
+ <application>rotatelogs</application> d'<productname>Apache</productname>
+ pour avoir une séquence de journaux applicatifs et éviter d'avoir des
+ journaux trop gros ;
+ </para>
+ </listitem>
-<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 journaux applicatifs.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
-<listitem><para> Purgez régulièrement les vieux fichiers de log.</para></listitem>
-
-</itemizedlist>
-</para>
</sect2>
-<sect2><title>service </title>
+<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>
+ 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 journaux applicatifs,
+ consultez la section logrep ci-dessous. Actuellement, ce script a 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>
+<para>
+ Pour les usages non-interactifs, configurez 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> et
+ <envar>SLON_BINARY</envar>. Si une seule 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>
+ <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 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>
+ Ce script utilise <command>tail -F</command> pour extraire des données des
+ journaux applicatifs en vous permettant d'utiliser des filtres multilog (via
+ l'option CRITERIA) afin de créer des journaux de transactions spécifiques.
+ Le but est de fournir un moyen de surveiller les journaux de transactions en
+ temps réel en quête de données <quote>intéressante</quote> sans devoir
+ modifier le journal applicatif initial ou gacher des ressources CPU/IO
+ en parcourant les journaux 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>
+ Pour une utilisation non interactive, il faut configurer les variables :
+ <envar>BASEDIR</envar>, <envar>SYSUSR</envar>, <envar>SOURCE</envar>,
+ <envar>EXTENSION</envar> et <envar>CRITERIA</envar>. Si une seule 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>
+ <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>, le nom du service de log que vous voulez utiliser.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>EXTENSION</envar>, une balise 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 :
+<para>
+ Un exemple trivial consiste à produire un journal applicatif de tous les
+ messages d'erreur slon qui pourraient être utilisés 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>)
+ <command>CRITERIA="'-*' '+* * ERROR*'"</command>
+ (on relance la surveillance en déclenchant une rotation des journaux
+ applicatifs 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>
+ Une application plus intéressante est la surveillance de la progression
+ d'une souscription d'un nœud :
+ <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 avez une trace d'abonnement, alors il est facile de déterminer si un
+ nœud donné est en train de réaliser une copie ou une autre activité de
+ souscription. Si les journaux applicatifs ne sont pas vide et ne se terminent
+ pas par <command>"CONFIG enableSubscription: sub_set:1"</command> (où 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>
+<para>
+ Si vous surveillez l'horodatage de modification du journal applicatif de
+ votre nœud primaire pour déterminer si le slon est tombé dans le coma,
+ vérifier cette trace d'abonnement est un bon moyen d'éviter de stopper le
+ nœud alors qu'un abonnement est en cours. En bonus, puisque les slons
+ utilisent 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 traces de COPY sont pratiques pour suivre de manière interactive
+ l'activité des abonnements.
+</para>
+
</sect3>
</sect2>
+
</sect1>
More information about the Trad
mailing list