Changeset 1072

Show
Ignore:
Timestamp:
06/11/08 11:04:23 (3 months ago)
Author:
daamien
Message:

1ere traduction à relire

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/maintenance.xml

    r969 r1072  
    55     révision $Revision$ --> 
    66 
    7 <sect1 id="maintenance"> <title>&slony1; Maintenance</title> 
    8  
    9 <indexterm><primary>maintaining &slony1;</primary></indexterm> 
    10  
    11 <para>&slony1; actually does a lot of its necessary maintenance 
    12 itself, in a <quote>cleanup</quote> thread: 
    13  
    14 <itemizedlist> 
    15  
    16 <listitem><para> Deletes old data from various tables in the 
    17 <productname>Slony-I</productname> cluster's namespace, notably 
    18 entries in <xref linkend="table.sl-log-1"/>, <xref 
     7<sect1 id="maintenance"> <title>Maintenance</title> 
     8 
     9<indexterm><primary>maintenir &slony1;</primary></indexterm> 
     10 
     11<para>&slony1; effectue une grande partie de sa maintenance 
     12de lui-même, dans un processus de <quote> 
     13nettoyage</quote> qui  : 
     14 
     15<itemizedlist> 
     16 
     17<listitem><para>supprime les anciennes donnéessur 
     18les différentes tables d'espace de nom de 
     19du cluster <productname>Slony-I</productname>, 
     20notamment <xref linkend="table.sl-log-1"/>, <xref 
    1921linkend="table.sl-log-2"/>, and <xref 
    20 linkend="table.sl-seqlog"/>.</para></listitem> 
    21  
    22 <listitem><para> Vacuum certain tables used by &slony1;.  As of 1.0.5, 
    23 this includes &pglistener;; in earlier versions, you must vacuum that 
    24 table heavily, otherwise you'll find replication slowing down because 
    25 &slony1; raises plenty of events, which leads to that table having 
    26 plenty of dead tuples.</para> 
    27  
    28 <para> In some versions (1.1, for sure; possibly 1.0.5) there is the 
    29 option of not bothering to vacuum any of these tables if you are using 
    30 something like <application>pg_autovacuum</application> to handle 
    31 vacuuming of these tables.  Unfortunately, it has been quite possible 
    32 for <application>pg_autovacuum</application> to not vacuum quite 
    33 frequently enough, so you may prefer to use the internal vacuums. 
    34 Vacuuming &pglistener; <quote>too often</quote> isn't nearly as 
    35 hazardous as not vacuuming it frequently enough.</para> 
    36  
    37 <para>Unfortunately, if you have long-running transactions, vacuums 
    38 cannot clear out dead tuples that are newer than the eldest 
    39 transaction that is still running.  This will most notably lead to 
    40 &pglistener; growing large and will slow 
    41 replication.</para></listitem> 
    42  
    43 <listitem> <para> The <link linkend="dupkey"> Duplicate Key Violation 
    44 </link> bug has helped track down some &postgres; race conditions. 
    45 One remaining issue is that it appears that is a case where 
    46 <command>VACUUM</command> is not reclaiming space correctly, leading 
    47 to corruption of B-trees. </para> 
    48  
    49 <para> It may be helpful to run the command <command> REINDEX TABLE 
    50 sl_log_1;</command> periodically to avoid the problem 
    51 occurring. </para> </listitem> 
    52  
    53 <listitem><para> As of version 1.2, <quote>log switching</quote> 
    54 functionality is in place; every so often, it seeks to switch between 
    55 storing data in &sllog1; and &sllog2; so that it may seek 
    56 to <command>TRUNCATE</command> the <quote>elder</quote> data.</para> 
    57  
    58 <para> That means that on a regular basis, these tables are completely 
    59 cleared out, so that you will not suffer from them having grown to 
    60 some significant size, due to heavy load, after which they are 
    61 incapable of shrinking back down </para> </listitem> 
    62  
    63 </itemizedlist> 
    64 </para> 
    65  
    66  
    67 <sect2 id="maintenance-autovac"> <title> Interaction with &postgres; 
    68 autovacuum </title> 
    69  
    70 <indexterm><primary>autovacuum interaction</primary></indexterm> 
    71  
    72 <para> Recent versions of &postgres; support an 
    73 <quote>autovacuum</quote> process which notices when tables are 
    74 modified, thereby creating dead tuples, and vacuums those tables, 
    75 <quote>on demand.</quote> It has been observed that this can interact 
    76 somewhat negatively with &slony1;'s own vacuuming policies on its own 
    77 tables. </para> 
    78  
    79 <para> &slony1; requests vacuums on its tables immediately after 
    80 completing transactions that are expected to clean out old data, which 
    81 may be expected to be the ideal time to do so.  It appears as though 
    82 autovacuum may notice the changes a bit earlier, and attempts 
    83 vacuuming when transactions are not complete, rendering the work 
    84 pretty useless.  It seems preferable to configure autovacuum to avoid 
    85 vacuum &slony1;-managed configuration tables. </para> 
    86  
    87 <para> The following query (change the cluster name to match your 
    88 local configuration) will identify the tables that autovacuum should 
    89 be configured not to process: </para> 
     22linkend="table.sl-seqlog"/>;</para></listitem> 
     23 
     24<listitem><para>effectue un vacuum sur certaines 
     25tables utilisées par &slony1;. 
     26A partir de la version 1.0.5, ceci inclut &pglistener;; 
     27dans les versions antérieures, vous devez lancer 
     28souvent des vacuums sur cette table, sinon 
     29vous verrez votre réplication ralentir 
     30car &slony1; lÚve beaucoup d'événets, 
     31qui mÚnent à table à contenir de nombreux 
     32tuples morts. 
     33</para> 
     34 
     35<para>Avec certaines versions (la 1.1; peut-être la 1.0.5) 
     36il est possible de ne plus s'embarrasser avec les vacuums 
     37sur ces tables si vous utiliser quelque chose comme 
     38<application>pg_autovacuum</application> 
     39pour gérer le nettoyage de ces tables. 
     40Malheureusement, il est possible que 
     41<application>pg_autovacuum</application>  
     42ne nettoie pas assez fréquemment, vous pourrez donc préférer utiliser les vacuums internes. 
     43 
     44Nettoyer la table &pglistener; <quote>trop  
     45souvent</quote> 
     46est moins risqué que de ne pas la nettoyer assez. 
     47</para> 
     48 
     49<para>Malheureusement, si vous avez de longues transactions, 
     50les vacuums ne peuvent pas nettoyer les tuples morts  
     51qui sont plus récents que les anciennes transactions  
     52toujours en cours. Ceci conduira en particulier à une  
     53forte croissance de &pglistener;  
     54et ralentira la réplication. 
     55</para></listitem> 
     56 
     57 
     58<listitem> <para> Le bug <link linkend="dupkey"> Violation par  
     59clef dupliqué</link> a permis d'isoler des situations de  
     60concurrence dans &postgres; 
     61Des problÚms subsiste notamment  
     62lorsque <command>VACUUM</command> ne  
     63réclame pas correctement l'espace  
     64menant à une corruption des arbres B. </para> 
     65 
     66<para>Il peut être utile de lancer la commande 
     67<command> REINDEX TABLE sl_log_1;</command> 
     68périodiquement pour éviter ce problÚm 
     69</para> </listitem> 
     70 
     71<listitem><para> A partir de la version 1.2, 
     72 la fonctionnalité <quote>log switching</quote> 
     73est arrivée;de temps en temps, elle tente d'interchanger 
     74les données entre &sllog1; and &sllog2;  
     75afin de réaliser un  
     76<command>TRUNCATE</command> sur les <quote>plus vielles</quote>  
     77données.</para> 
     78 
     79<para> Cela signifie que de maniÚre réguliÚre, 
     80ces tables sont complÚtement nettoyées ce qui 
     81évitequ'elle ne grossisse trop  
     82lors d'une charge importante  
     83et qu'elles deviennent 
     84impossible à nettoyer. 
     85 
     86</para> </listitem> 
     87 
     88</itemizedlist> 
     89</para> 
     90 
     91 
     92<sect2 id="maintenance-autovac">  
     93<title> Intéraction avec l'autovaccum de &postgres; 
     94</title> 
     95 
     96<indexterm><primary>interaction avec autovacuum</primary></indexterm> 
     97 
     98<para>Les versions récentes de&postgres; propose 
     99un processus <quote>autovacuum</quote>  
     100qui détecte les modifications sur les tables et la 
     101création 
     102de tuples mort, puis nettoie de ces tables,  
     103<quote>à la demande.</quote>. 
     104On a constaté que cela peut interagir de maniÚre 
     105négative avec la politique de vacuum de &slony1; 
     106sur ces propres tables. </para> 
     107 
     108<para> &slony1; demande des vacuums sur ses tables 
     109immédiatement aprÚs avoir complété les 
     110transactions 
     111qui sont sensées supprimer de vieilles données, 
     112ce qui est considéré comme le meilleur moment  
     113pour le faire. Il semble que l'autovacuum détecte  
     114les changements un peu trop tÃŽt, et lance un vacuum 
     115alors que les transactions ne sont pas complétées, 
     116ce qui est relativement inutile. 
     117Il apparait préférable de configurer l'autovacuum 
     118pour éviter les tables de configuration 
     119gérées par &slony1;. </para> 
     120 
     121<para> La requête suivante identifie les tables que  
     122l'autovacuum ne doit pas traiter (remplacez le nom du 
     123cluster par celui de votre configuration locale) : 
     124</para> 
    90125 
    91126<programlisting> 
    92 mycluster=# select oid, relname from pg_class where relnamespace = (select oid from pg_namespace where nspname = '_' || 'MyCluster') and relhasindex; 
     127moncluster=# select oid, relname from pg_class where relnamespace = (select oid from pg_namespace where nspname = '_' || 'monCluster') and relhasindex; 
    93128  oid  |   relname     
    94129-------+-------------- 
    …… 
    111146</programlisting> 
    112147 
    113 <para> The following query will populate 
    114 <envar>pg_catalog.pg_autovacuum</envar> with suitable configuration 
    115 information: <command> insert into pg_catalog.pg_autovacuum (vacrelid, 
     148<para>La requête suivante remplira la table  
     149<envar>pg_catalog.pg_autovacuum</envar>  
     150avec les informations de configuration adéquates : 
     151<command> insert into pg_catalog.pg_autovacuum (vacrelid, 
    116152enabled) select oid, 'f' from pg_catalog.pg_class where relnamespace = 
    117 (select oid from pg_namespace where nspname = '_' || 'MyCluster') and 
     153(select oid from pg_namespace where nspname = '_' || 'monCluster') and 
    118154relhasindex; </command> </para> 
    119155</sect2> 
    120156 
    121 <sect2><title> Watchdogs: Keeping Slons Running</title> 
    122  
    123 <indexterm><primary>watchdogs to keep slon daemons running</primary></indexterm> 
    124  
    125 <para>There are a couple of <quote>watchdog</quote> scripts available 
    126 that monitor things, and restart the <application>slon</application> 
    127 processes should they happen to die for some reason, such as a network 
    128 <quote>glitch</quote> that causes loss of connectivity.</para> 
    129  
    130 <para>You might want to run them...</para> 
    131  
    132 <para> The <quote>best new way</quote> of managing <xref 
    133 linkend="slon"/> processes is via the combination of <xref 
    134 linkend="mkslonconf"/>, which creates a configuration file for each 
    135 node in a cluster, and <xref linkend="launchclusters"/>, which uses 
    136 those configuration files.</para> 
    137  
    138 <para> This approach is preferable to elder <quote>watchdog</quote> 
    139 systems in that you can very precisely <quote>nail down,</quote> in 
    140 each config file, the exact desired configuration for each node, and 
    141 not need to be concerned with what options the watchdog script may or 
    142 may not give you.  This is particularly important if you are using 
    143 <link linkend="logshipping"> log shipping </link>, where forgetting 
    144 the <command>-a</command> option could ruin your log shipped node, and 
    145 thereby your whole day.</para> 
    146  
    147 </sect2> 
    148  
    149 <sect2 id="gensync"><title>Parallel to Watchdog: generate_syncs.sh</title> 
    150  
    151 <indexterm><primary>generate SYNCs</primary></indexterm> 
    152  
    153 <para>A new script for &slony1; 1.1 is 
    154 <application>generate_syncs.sh</application>, which addresses the following kind of 
    155 situation.</para> 
    156  
    157 <para>Supposing you have some possibly-flakey server where the 
    158 <application>slon</application> daemon that might not run all the time, you might 
    159 return from a weekend away only to discover the following situation.</para> 
    160  
    161 <para>On Friday night, something went <quote>bump</quote> and while the 
    162 database came back up, none of the <application>slon</application> daemons 
    163 survived.  Your online application then saw nearly three days worth of 
    164 reasonably heavy transaction load.</para> 
    165  
    166 <para>When you restart <application>slon</application> on Monday, it 
    167 hasn't done a SYNC on the master since Friday, so that the next 
    168 <quote>SYNC set</quote> comprises all of the updates between Friday 
    169 and Monday.  Yuck.</para> 
    170  
    171 <para>If you run <application>generate_syncs.sh</application> as a cron job every 
    172 20 minutes, it will force in a periodic <command>SYNC</command> on the origin, which 
    173 means that between Friday and Monday, the numerous updates are split 
    174 into more than 100 syncs, which can be applied incrementally, making 
    175 the cleanup a lot less unpleasant.</para> 
    176  
    177 <para>Note that if <command>SYNC</command>s <emphasis>are</emphasis> running 
    178 regularly, this script won't bother doing anything.</para> 
    179 </sect2> 
    180  
    181 <sect2><title>Testing &slony1; State </title> 
    182  
    183 <indexterm><primary>testing cluster status</primary></indexterm> 
    184  
    185 <para> In the <filename>tools</filename> directory, you may find 
    186 scripts called <filename>test_slony_state.pl</filename> and 
    187 <filename>test_slony_state-dbi.pl</filename>.  One uses the Perl/DBI 
    188 interface; the other uses the Pg interface. 
    189 </para> 
    190  
    191 <para> Both do essentially the same thing, namely to connect to a 
    192 &slony1; node (you can pick any one), and from that, determine all the 
    193 nodes in the cluster.  They then run a series of queries (read only, 
    194 so this should be quite safe to run) which look at the various 
    195 &slony1; tables, looking for a variety of sorts of conditions 
    196 suggestive of problems, including: 
    197 </para> 
    198  
    199 <itemizedlist> 
    200 <listitem><para> Bloating of tables like pg_listener, sl_log_1, sl_log_2, sl_seqlog </para></listitem> 
    201 <listitem><para> Listen paths </para></listitem> 
    202 <listitem><para> Analysis of Event propagation </para></listitem> 
    203 <listitem><para> Analysis of Event confirmation propagation </para>  
    204  
    205 <para> If communications is a <emphasis>little</emphasis> broken, 
    206 replication may happen, but confirmations may not get back, which 
    207 prevents nodes from clearing out old events and old replication 
    208 data. </para> </listitem> 
    209 </itemizedlist> 
    210  
    211 <para> Running this once an hour or once a day can help you detect 
    212 symptoms of problems early, before they lead to performance 
    213 degradation. </para> 
    214 </sect2> 
    215  
    216 <sect2><title>Replication Test Scripts </title> 
    217  
    218 <para> In the directory <filename>tools</filename> may be found four 
    219 scripts that may be used to do monitoring of &slony1; instances: 
    220  
    221 <itemizedlist> 
    222  
    223 <listitem><para> <command>test_slony_replication</command> is a 
    224 Perl script to which you can pass connection information to get to a 
    225 &slony1; node.  It then queries <xref linkend="table.sl-path"/> and 
    226 other information on that node in order to determine the shape of the 
    227 requested replication set.</para> 
    228  
    229 <para> It then injects some test queries to a test table called 
    230 <envar>slony_test</envar> which is defined as follows, and which needs to be 
    231 added to the set of tables being replicated: 
     157<sect2><title> Chiens de garde : garder les Slons en vie</title> 
     158 
     159<indexterm><primary>Chiens de garde pour garder en vie les démons slon  
     160</primary></indexterm> 
     161 
     162<para>Il y a deux scripts <quote>chiens de garde</quote> disponibles pour surveiller 
     163  la réplication et relancer les processus <application>slon</application> 
     164  lorsqu'il meurent pour telle ou telle raison, par exemple une    
     165<quote>coupure</quote> réseau qui provoque une perte de connectivité.</para> 
     166 
     167<para>Ils pourraient vous être utiles...</para> 
     168 
     169<para> La <quote>meilleur et nouvelle</quote> façon de gérer les processus <xref 
     170linkend="slon"/> se fait via une combinaison de  <xref 
     171linkend="mkslonconf"/>, qui crée un fichier de configuration pour chaque noeud 
     172  d'un cluster, et <xref linkend="launchclusters"/> qui utilise ces fichiers  
     173  de configuration.</para> 
     174 
     175<para> Cette approche est préférable aux anciens systÚmes de  
     176  <quote>chiens de garde</quote> car vous pouvez <quote>pointer</quote> 
     177  précisément, dans chaque fichier de configurationn, le paramÚtrage  
     178  désiré pour chaque noeud, sans avoir à vous préoccuper des options 
     179  que le script chien de garde vous proposer ( ou pas ). Ceci est particuliÚrement 
     180  important si vous utilisez le <link linkend="logshipping"> log shipping </link>,  
     181  auquel cas oublier l'option <command>-a</command> peut ruiner le noeud  
     182  destinataire du log shipping et ruiner par là-même votre journée.</para> 
     183 
     184</sect2> 
     185 
     186<sect2 id="gensync"><title>En parallÚle aux chiens de garde : generate_syncs.sh</title> 
     187 
     188<indexterm><primary>Génére des SYNCs</primary></indexterm> 
     189 
     190<para>Un nouveau script est apparu dans &slony1; 1.1, il s'agit de  
     191<application>generate_syncs.sh</application>, qui est utilise dans les situations 
     192suivantes.</para> 
     193 
     194<para>Supposons que vous avez un serveur non fiable sur lequel le démon  
     195<application>slon</application> daemon ne fonctionne pas en continu, 
     196en rentrant de week-end vous vous trouverez peut-êtrÚs la situation suivante : 
     197</para> 
     198 
     199<para>Le vendredi soir, quelque chose s'est <quote>cassé</quote> et le temps  
     200  que la base de donnée redémarre, aucun des démons <application>slon</application> 
     201  n'a survécu. Votre application en ligne a ensuite connu trois jours  
     202  de charge transactionnelle relativement forte. 
     203  </para> 
     204 
     205<para>Lorsque vous redémarrez <application>slon</application> le lundi, il n'y a pas eu  
     206  de synchronisation sur le maître depuis Vendredi, ce qui fait que le prochain  
     207<quote>ensemble de SYNC</quote> comprendra toutes les modifications entre vendredi  
     208et lundi. Aïe !</para> 
     209 
     210<para>Si vous lancez <application>generate_syncs.sh</application> via une tache cron 
     211  toute les 20 minutes, cela créera de force des événements <command>SYNC</command> 
     212  sur l'origine, ce qui implique qu'entre vendredi et lundi, les nombreuses mises à jour 
     213  seront découpées en plus de 100 ensemble de SYNCs, qui pourront être appliqués de  
     214  maniÚre incrémentale, rendant la restauration mois déplaisante. 
     215</para> 
     216 
     217<para>Notez que si les <command>SYNC</command>s <emphasis>sont</emphasis> exécutés  
     218  réguliÚrement, ce scripts ne fera rien de particulier.</para> 
     219</sect2> 
     220 
     221<sect2><title>Tester l'état &slony1; </title> 
     222 
     223<indexterm><primary>tester le statut du cluster</primary></indexterm> 
     224 
     225<para> Dans le répertoire <filename>tools</filename>, vous trouverez 
     226  des scripts nommés <filename>test_slony_state.pl</filename> et 
     227<filename>test_slony_state-dbi.pl</filename>.  Le premier utilise l'interface Perl/DBI 
     228; l'autre utilise l'interface Pg. 
     229</para> 
     230 
     231<para> Les deux font essentiellement la même chose, c'est à dire 
     232  se connecter à un noeud &slony1; (celui de votre choix) et à partir de là 
     233  détermine la liste des noeuds du cluster. Ensuite ils lancent une 
     234  série de requêtes ( en lecture seule, et donc sans danger ) afin  
     235  de parcourir différentes tables à la recherche de différentes conditions 
     236  susceptibles de rélever des problÚmes, telles que : 
     237</para> 
     238 
     239<itemizedlist> 
     240<listitem><para> Gonflement des tables comme pg_listener, sl_log_1, sl_log_2, sl_seqlog; </para></listitem> 
     241<listitem><para> Voies d'écoute;</para></listitem> 
     242<listitem><para> Analyse de la propagation des événéments; </para></listitem> 
     243<listitem><para> Analyse de la propagation des confirmations. </para>  
     244 
     245<para> Si la communication est <emphasis>légÚrement</emphasis> perturbée, 
     246la réplication peut fonctionner, mais les confirmations peuvent ne pas être retournées, 
     247ce qui empêche les noeuds de nettoyer les vieux événements et les anciennes données de réplication 
     248. </para> </listitem> 
     249</itemizedlist> 
     250 
     251<para> Lancer ce script une par heure ou une fois par jour peut vous aider 
     252  à détecter les symptomes précurseurs de certains problÚmes, avant même 
     253  que cela conduise à une dégradation des performances. </para> 
     254</sect2> 
     255 
     256<sect2><title>Scripts de test de la réplication</title> 
     257 
     258<para>Dans le répertoire <filename>tools</filename> on peut trouver 4 
     259  scripts qui peuvent être utilisés pour surveiller des instances &slony1; : 
     260 
     261<itemizedlist> 
     262 
     263<listitem><para> <command>test_slony_replication</command> est un script  
     264    Perl auquel vous pouvez passer les informations de connexion 
     265    d'un noeud &slony1;.  Il test alors la table  <xref linkend="table.sl-path"/> 
     266    et d'autres informations sur ce noeud afin de déterminer la forme de 
     267    l'ensemble de réplication choisi.</para> 
     268 
     269<para> Ensuite il injecte des requêtes de test dans la table nommée 
     270<envar>slony_test</envar> qui est définie comme ci-dessous, et 
     271qui doit être ajoutée à l'ensemble des tables répliquées : 
    232272 
    233273<programlisting> 
    …… 
    239279</programlisting></para> 
    240280 
    241 <para> The last column in that table was defined by &slony1; as one 
    242 lacking a primary key...</para> 
    243  
    244 <para> This script generates a line of output for each &slony1; node 
    245 that is active for the requested replication set in a file called 
    246 <filename>cluster.fact.log</filename>.</para> 
    247  
    248 <para> There is an additional <option>finalquery</option> option that allows 
    249 you to pass in an application-specific SQL query that can determine 
    250 something about the state of your application.</para></listitem> 
    251  
    252 <listitem><para><command>log.pm</command> is a Perl module that manages logging 
    253 for the Perl scripts.</para></listitem> 
    254  
    255 <listitem><para><command>run_rep_tests.sh</command> is a <quote>wrapper</quote> script 
    256 that runs <command>test_slony_replication</command>.</para> 
    257  
    258 <para> If you have several &slony1; clusters, you might set up 
    259 configuration in this file to connect to all those 
     281<para> La derniÚre colonne de la table est définie par &slony1; comme 
     282  une une clé primaire manquante...</para> 
     283 
     284<para> Ce script génÚre une ligne de sortie pour chaque noeud &slony1; actif 
     285  pour l'ensemble de réplication défini dans un fichier nommé  
     286  <filename>cluster.fact.log</filename>.</para> 
     287 
     288<para> Il y a une option additionelle, <option>finalquery</option>, qui vous permet de 
     289  passer une requête SQL spécifique à votre application pour déterminer 
     290 l'état de votre application.</para></listitem> 
     291 
     292<listitem><para><command>log.pm</command> est un module Perl module qui gÚre les logs des  
     293    scripts Perl.</para></listitem> 
     294 
     295<listitem><para><command>run_rep_tests.sh</command> est un script <quote>wrapper</quote> 
     296    qui lance <command>test_slony_replication</command>.</para> 
     297 
     298<para> Si vous avez plusieurs clusters &slony1;, vous pouvez placer dans  
     299  ce fichier le configuration pour se connecter à tous ces  
    260300clusters.</para></listitem> 
    261301 
    262 <listitem><para><command>nagios_slony_test</command> is a script that 
    263 was constructed to query the log files so that you might run the 
    264 replication tests every so often (we run them every 6 minutes), and 
    265 then a system monitoring tool such as <ulink 
     302<listitem><para><command>nagios_slony_test</command> est un script qui 
     303    a été construit pour interroger les fichiers logs afin de pouvoir 
     304    lancer le test de réplication réguliÚrement ( nous le laissons  
     305    toutes les 6 minutes) et qu'un outil de supervision tel que  
     306 <ulink 
    266307url="http://www.nagios.org/"> <productname>Nagios</productname> 
    267 </ulink> can be set up to use this script to query the state indicated 
    268 in those logs.</para> 
    269  
    270 <para> It seemed rather more efficient to have a 
    271 <application>cron</application> job run the tests and have 
    272 <productname>Nagios</productname> check the results rather than having 
    273 <productname>Nagios</productname> run the tests directly.  The tests 
    274 can exercise the whole &slony1; cluster at once rather than 
    275 <productname>Nagios</productname> invoking updates over and over 
    276 again.</para></listitem> 
     308</ulink> puisse utiliser le script to surveiller l'état indiqué  
     309dans ces logs.</para> 
     310 
     311<para> Il semble plus efficace qu'une tache 
     312<application>cron</application> lance les tests et que  
     313<productname>Nagios</productname> vérifie le résultat plutÃŽt que 
     314de voir <productname>Nagios</productname> lancer directement  
     315les tests.  Ces tests peuvent vérifier l'ensemble du cluster &slony1; 
     316d'un seul coup, plutot que de voir <productname>Nagios</productname>  
     317provoque des mises à jour en permanence.</para></listitem> 
    277318 
    278319</itemizedlist></para> 
    279320</sect2> 
    280321 
    281 <sect2><title> Other Replication Tests </title> 
    282  
    283 <indexterm><primary>testing replication</primary></indexterm>   
     322<sect2><title> Autres tests de réplication</title> 
     323 
     324<indexterm><primary>tester la réplication</primary></indexterm>   
    284325   
    285 <para> The methodology of the previous section is designed with a view 
    286 to minimizing the cost of submitting replication test queries; on a 
    287 busy cluster, supporting hundreds of users, the cost associated with 
    288 running a few queries is likely to be pretty irrelevant, and the setup 
    289 cost to configure the tables and data injectors is pretty high.</para> 
    290  
    291 <para> Three other methods for analyzing the state of replication have 
    292 stood out:</para> 
    293  
    294 <itemizedlist> 
    295  
    296 <listitem><para> For an application-oriented test, it has been useful 
    297 to set up a view on some frequently updated table that pulls 
    298 application-specific information.  </para> 
    299  
    300 <para> For instance, one might look either at some statistics about a 
    301 most recently created application object, or an application 
    302 transaction.  For instance:</para> 
     326<para> La méthodologie de la section précédente est conçu avec un vue 
     327  pour minimiser le coût des requêtes de test; sur un cluster trÚs chargé, 
     328  supportant des centaines d'utilisateurs, le coût associé aux quelques 
     329  requêtes de test n'est un point important et le temps de configuration 
     330  des tables et des injecteurs de données est trÚs élevé.</para> 
     331 
     332<para> 3 autres méthodes pour analyser l'état de la réplication sont  
     333apparus :</para> 
     334 
     335<itemizedlist> 
     336 
     337<listitem><para> Pour un test orienté sur l'application, il est utile  
     338    de créer une vue sur une table fréquemment mise à jour pour remonter 
     339    des informations spécifique à l'application.</para> 
     340 
     341<para> Par exemple, on peut chercher soit des statistiques 
     342  sur les objets applicatif les plus récents, soit les transactions  
     343  de l'applicatio. Par exemple :</para> 
    303344 
    304345<para> <command> create view replication_test as select now() - 
    …… 
    310351limit 1; </command> </para> 
    311352 
    312 <para> There is a downside: This approach requires that you have 
    313 regular activity going through the system that will lead to there 
    314 being new transactions on a regular basis.  If something breaks down 
    315 with your application, you may start getting spurious warnings about 
    316 replication being behind, despite the fact that replication is working 
    317 fine.</para> 
     353<para> Il y a un inconvénient : Cette approche nécessite que vous  
     354  ayez une activité constante sur le systÚme impliquant la création 
     355  de nouvelles transactions de maniÚre réguliÚre. 
     356  Si quelque chose ne fonctionne pas dans votre application. vous obtiendrez  
     357  des fausses alertes en provenance de la réplication, alors même que la réplication 
     358  fonctionne correctement.</para> 
    318359 
    319360</listitem> 
    320361 
    321 <listitem><para> The &slony1;-defined view, <envar>sl_status</envar> 
    322 provides information as to how up to date different nodes are.  Its 
    323 contents are only really interesting on origin nodes, as the events 
    324 generated on other nodes are generally ignorable. </para> 
     362<listitem><para> La vue  &slony1; nommée <envar>sl_status</envar> 
     363    fournit des informations sur la synchronisation des différents noeuds. 
     364    Son contenu n'est intéressant que sur les noeuds origine, car les 
     365    événements générés sur les autres noeuds peuvent généralement 
     366    être ignorés. </para> 
    325367</listitem> 
    326368 
    327 <listitem><para> See also the <xref linkend="slonymrtg"/> 
    328 discussion. </para></listitem> 
    329  
    330 </itemizedlist> 
    331 </sect2> 
    332 <sect2><title> Log Files</title> 
    333  
    334 <indexterm><primary>log files</primary></indexterm> 
    335  
    336 <para><xref linkend="slon"/> daemons generate some more-or-less verbose 
    337 log files, depending on what debugging level is turned on.  You might 
    338 assortedly wish to: 
    339  
    340 <itemizedlist> 
    341  
    342 <listitem><para> Use a log rotator like 
    343 <productname>Apache</productname> 
    344 <application>rotatelogs</application> to have a sequence of log files 
    345 so that no one of them gets too big;</para></listitem> 
    346  
    347 <listitem><para> Purge out old log files, 
    348 periodically.</para></listitem> 
    349  
    350 </itemizedlist> 
    351 </para> 
    352 </sect2> 
    353  
    354 <sect2><title>mkservice </title> 
    355 <indexterm><primary>mkservice for BSD </primary></indexterm> 
    356  
    357 <sect3><title>slon-mkservice.sh</title> 
    358  
    359 <para> Create a slon service directory for use with svscan from 
    360 daemontools.  This uses multilog in a pretty basic way, which seems to 
    361 be standard for daemontools / multilog setups. If you want clever 
    362 logging, see logrep below. Currently this script has very limited 
    363 error handling capabilities.</para> 
    364  
    365 <para> For non-interactive use, set the following environment 
    366 variables.  <envar>BASEDIR</envar> <envar>SYSUSR</envar> 
     369<listitem><para> Voir également la discussion sur <xref linkend="slonymrtg"/>. </para></listitem> 
     370 
     371</itemizedlist> 
     372</sect2> 
     373<sect2><title> Fichiers de log</title> 
     374 
     375<indexterm><primary>fichiers de log</primary></indexterm> 
     376 
     377<para>Les démons <xref linkend="slon"/> génÚre des fichiers de logs plus  
     378  ou moins verbeux, selon le niveau de debug activé. Dans ce cas vous pouvez : 
     379 
     380<itemizedlist> 
     381 
     382<listitem><para> Utiliser un programme de rotations de logs comme 
     383<application>rotatelogs</application> d'<productname>Apache</productname> 
     384 pour avoir une sécancer de fichiers de logs et évite d'avoir des fichiers 
     385trop gros;</para></listitem> 
     386 
     387<listitem><para> Purgez réguliÚrement les vieux fichiers de log.</para></listitem> 
     388 
     389</itemizedlist> 
     390</para> 
     391</sect2> 
     392 
     393<sect2><title>service </title> 
     394<indexterm><primary>service pour BSD </primary></indexterm> 
     395 
     396<sect3><title>slon</title> 
     397 
     398<para> Ce script crée un répertoire pour le service slon qui pourra être  
     399  utilisé avec la commande svscan de daemontools. Ce script utilise multilog  
     400  de maniÚre trÚs basique, ce qui semble être standard pour les installations 
     401  daemontools / multilog. Si vous souhaitez une gestion intelligente des logs, 
     402  consultez la section logrep ci-dessous. Actuellement ce script à des possibilités 
     403  de gestion d'erreurs trÚs limitées. 
     404  </para> 
     405 
     406<para> Pour les usages non-interactifs, configurer les variables d'environnement 
     407  suivantes :  <envar>BASEDIR</envar> <envar>SYSUSR</envar> 
    367408<envar>PASSFILE</envar> <envar>DBUSER</envar> <envar>HOST</envar> 
    368409<envar>PORT</envar> <envar>DATABASE</envar> <envar>CLUSTER</envar> 
    369 <envar>SLON_BINARY</envar> If any of the above are not set, the script 
    370 asks for configuration information interactively.</para> 
    371  
    372 <itemizedlist> 
    373 <listitem><para> 
    374 <envar>BASEDIR</envar> where you want the service directory structure for the slon 
    375 to be created. This should <emphasis>not</emphasis> be the <filename>/var/service</filename> directory.</para></listitem> 
    376 <listitem><para> 
    377 <envar>SYSUSR</envar> the unix user under which the slon (and multilog) process should run.</para></listitem> 
    378 <listitem><para> 
    379 <envar>PASSFILE</envar> location of the <filename>.pgpass</filename> file to be used. (default <filename>~sysusr/.pgpass</filename>)</para></listitem> 
    380 <listitem><para> 
    381 <envar>DBUSER</envar> the postgres user the slon should connect as (default slony)</para></listitem> 
    382 <listitem><para> 
    383 <envar>HOST</envar> what database server to connect to (default localhost)</para></listitem> 
    384 <listitem><para> 
    385 <envar>PORT</envar> what port to connect to (default 5432)</para></listitem> 
    386 <listitem><para> 
    387 <envar>DATABASE</envar> which database to connect to (default dbuser)</para></listitem> 
    388 <listitem><para> 
    389 <envar>CLUSTER</envar> the name of your Slony1 cluster? (default database)</para></listitem> 
    390 <listitem><para> 
    391 <envar>SLON_BINARY</envar> the full path name of the slon binary (default <command>which slon</command>)</para></listitem> 
     410<envar>SLON_BINARY</envar> Si un seul de ces valeurs n'est pas définie,  
     411le script demande les informations de maniÚre interactive.</para> 
     412 
     413<itemizedlist> 
     414<listitem><para> 
     415<envar>BASEDIR</envar> l'emplacement où la structure du répertoire du service slon sera créée. 
     416Il ne faut <emphasis>pas</emphasis> que ce soit le répertoire <filename>/var/service</filename>;</para></listitem> 
     417<listitem><para> 
     418<envar>SYSUSR</envar> l'utilisateur unix qui lancera le processus slon (et multilog);</para></listitem> 
     419<listitem><para> 
     420<envar>PASSFILE</envar> l'emplacement du fichier <filename>.pgpass</filename>. (par défaut <filename>~sysusr/.pgpass</filename>);</para></listitem> 
     421<listitem><para> 
     422<envar>DBUSER</envar> L'utilisateur postgres que slon doit utiliser ( par défaut slony);</para></listitem> 
     423<listitem><para> 
     424<envar>HOST</envar> l'adresse du serveur ou le slon doit se connecter (par défaut localhost)</para></listitem> 
     425<listitem><para> 
     426<envar>PORT</envar> le port de connexion (par défaut 5432)</para></listitem> 
     427<listitem><para> 
     428<envar>DATABASE</envar> la base de données sur laquelle slon se connecte (par défaut dbuser)</para></listitem> 
     429<listitem><para> 
     430<envar>CLUSTER</envar> le nom du cluster Slony1 (par défaut database)</para></listitem> 
     431<listitem><para> 
     432<envar>SLON_BINARY</envar> le chemin complet vers le binaire slon (par défaut <command>which slon</command>)</para></listitem> 
    392433</itemizedlist> 
    393434</sect3> 
    394435<sect3><title>logrep-mkservice.sh</title> 
    395436 
    396 <para>This uses <command>tail -F</command> to pull data from log files allowing 
    397 you to use multilog filters (by setting the CRITERIA) to create 
    398 special purpose log files. The goal is to provide a way to monitor log 
    399 files in near realtime for <quote>interesting</quote> data without either 
    400 hacking up the initial log file or wasting CPU/IO by re-scanning the 
    401 same log repeatedly. 
    402 </para> 
    403  
    404 <para>For non-interactive use, set the following environment 
    405 variables.  <envar>BASEDIR</envar> <envar>SYSUSR</envar> <envar>SOURCE</envar> 
    406 <envar>EXTENSION</envar> <envar>CRITERIA</envar> If any of the above are not set, 
    407 the script asks for configuration information interactively. 
    408 </para> 
    409  
    410 <itemizedlist> 
    411 <listitem><para> 
    412 <envar>BASEDIR</envar> where you want the service directory structure for the logrep 
    413 to be created. This should <emphasis>not</emphasis> be the <filename>/var/service</filename> directory.</para></listitem> 
    414 <listitem><para><envar>SYSUSR</envar> unix user under which the service should run.</para></listitem> 
    415 <listitem><para><envar>SOURCE</envar> name of the service with the log you want to follow.</para></listitem> 
    416 <listitem><para><envar>EXTENSION</envar> a tag to differentiate this logrep from others using the same source.</para></listitem> 
    417 <listitem><para><envar>CRITERIA</envar> the multilog filter you want to use.</para></listitem> 
    418 </itemizedlist> 
    419  
    420 <para> A trivial example of this would be to provide a log file of all slon 
    421 ERROR messages which could be used to trigger a nagios alarm. 
    422 <command>EXTENSION='ERRORS'</command> 
     437<para>Ce script utilise <command>tail -F</command> pour extraire des données des fichiers 
     438  de logs en vous permettant d'utiliser des filtres multilog (via l'option CRITERIA) afin 
     439  de créer des fichiers de logs spécifiques. Le but est de fournir un moyen de surveiller 
     440  les fichiers de logs en temps réel en quête de données  <quote>intéressante</quote> 
     441  sans devoir modifier le fichier de log initial ou gacher des ressources CPU/IO  
     442  en re-scannant les logs réguliÚrement. 
     443</para> 
     444 
     445<para>Pour une utilisation non interactive, il faut configurer les variable: 
     446  <envar>BASEDIR</envar> <envar>SYSUSR</envar> <envar>SOURCE</envar> 
     447<envar>EXTENSION</envar> <envar>CRITERIA</envar>. Si une seul de ces options n'est  
     448pas définie le script demande interactivement les informations de configuration. 
     449</para> 
     450 
     451<itemizedlist> 
     452<listitem><para> 
     453<envar>BASEDIR</envar> : l'emplacement où sera créée la structure du répertoire du service de logrep. 
     454Il ne faut <emphasis>pas</emphasis> que ce soit le répertoire <filename>/var/service</filename>. 
     455</para></listitem> 
     456<listitem><para><envar>SYSUSR</envar> : l'utilisateur unix qui lancera le service.</para></listitem> 
     457<listitem><para><envar>SOURCE</envar> : nom du service de log que vous voulez suivre.</para></listitem> 
     458<listitem><para><envar>EXTENSION</envar> : un tag pour différencier ce logrep de ceux qui utilisent la même source.</para></listitem> 
     459<listitem><para><envar>CRITERIA</envar> : le filtre multilog que vous voulez utiliser.</para></listitem> 
     460</itemizedlist> 
     461 
     462<para> Un exemple trivial consiste à produire un fichier de log de tous les messages d'erreur 
     463  slon qui pourrait être utilisé pour déclencher une alerte nagios : 
     464  <command>EXTENSION='ERRORS'</command> 
    423465<command>CRITERIA="'-*' '+* * ERROR*'"</command> 
    424 (Reset the monitor by rotating the log using <command>svc -a $svc_dir</command>) 
    425 </para> 
    426  
    427 <para> A more interesting application is a subscription progress log. 
     466(On relance la surveillance en déclenchant une rotation des logs avec <command>svc -a $svc_dir</command>) 
     467</para> 
     468 
     469<para> Une application plus intéressante est la surveillance de la progression d'une souscription d'un noeud : 
    428470<command>EXTENSION='COPY'</command> 
    429471<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> 
    430472</para> 
    431473 
    432 <para>If you have a subscription log then it's easy to determine if a given 
    433 slon is in the process of handling copies or other subscription activity. 
    434 If the log isn't empty, and doesn't end with a  
     474<para>Si vous avez un log de suscription, alors il est facile 
     475  de déterminer si un noeud donné est en train de réaliser une copie  
     476  ou une autre activité de souscription. Si les log ne sont pas vide et  
     477  ne se termine pas par   
    435478<command>"CONFIG enableSubscription: sub_set:1"</command> 
    436 (or whatever set number you've subscribed) then the slon is currently in 
    437 the middle of initial copies.</para> 
    438  
    439 <para> If you happen to be monitoring the mtime of your primary slony logs to  
    440 determine if your slon has gone brain-dead, checking this is a good way 
    441 to avoid mistakenly clobbering it in the middle of a subscribe. As a bonus, 
    442 recall that since the the slons are running under svscan, you only need to 
    443 kill it (via the svc interface) and let svscan start it up again laster. 
    444 I've also found the COPY logs handy for following subscribe activity  
    445 interactively.</para> 
     479(ou 1 est le numéro d'ensemble de réplication que vous avez abonné) 
     480alors le slon est au milieu d'une copie initiale.</para> 
     481 
     482<para> Si vous surveiller le mtime du fichier de log de votre noeud primaire 
     483  pour déterminer si le slon est tombé dans le coma, vérifier ce log de souscription  
     484  est un bon moyen d'éviter de stopper le noeud alors qu'un souscription est en cours. 
     485  En bonus, puisque les slons utilise svscan, vous pouvez simplement détruire le fichier 
     486  ( via l'interface svc ) et laisser svscan le recommencer plus tard. J'ai également  
     487  découvert que les logs de COPY sont pratiques pour suivre de maniÚre interactive 
     488  l'activité des souscritpions. 
     489  </para> 
    446490</sect3> 
    447491