Changeset 1085

Show
Ignore:
Timestamp:
07/03/08 10:38:09 (2 months ago)
Author:
daamien
Message:

Slony : Log Shipping : 1ere traduction (à relire)

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/logshipping.xml

    r937 r1085  
    66 
    77<sect1 id="logshipping"> 
    8 <title>Log Shipping - &slony1; with Files</title> 
     8<title>Log Shipping</title> 
    99<indexterm><primary>log shipping</primary></indexterm> 
    1010 
    11 <para> One of the new features for 1.1, that only really stabilized as 
    12 of 1.2.11, is the ability to serialize the updates to go out into log 
    13 files that can be kept in a spool directory.</para> 
    14  
    15 <para> The spool files could then be transferred via whatever means 
    16 was desired to a <quote>slave system,</quote> whether that be via FTP, 
    17 rsync, or perhaps even by pushing them onto a 1GB <quote>USB 
    18 key</quote> to be sent to the destination by clipping it to the ankle 
    19 of some sort of <quote>avian transport</quote> system.</para> 
    20  
    21 <para> There are plenty of neat things you can do with a data stream 
    22 in this form, including: 
    23  
     11<para> Une des nouvelles fonctionnalités de la version 1.1, qui  
     12  ne fut réellement stable qu'à partir de la version 1.2.11,  
     13  est la possibilité de regrouper les mises à jour dans des fichiers 
     14  de logs qui sont stockés dans un répertoire d'attente. 
     15  </para> 
     16 
     17<para> Ces fichiers de log peuvent alors être transférés selon la 
     18  méthode de votre choix vers le <quote>serveur esclave</quote>, 
     19  que ce soit via   FTP, rsync, ou même avec une <quote>clé USB</quote>  
     20  d' 1GB <quote> transportée par avion.</para> 
     21 
     22<para> Il y a plein de choses sympas à faire avec un tel flux de donnée, 
     23  en particulier : 
    2424<itemizedlist> 
    2525   
    26   <listitem><para> Replicating to nodes that 
    27   <emphasis>aren't</emphasis> securable</para></listitem> 
    28  
    29   <listitem><para> Replicating to destinations where it is not 
    30   possible to set up bidirection communications</para></listitem> 
    31  
    32   <listitem><para> Supporting a different form of <acronym>PITR</acronym> 
    33   (Point In Time Recovery) that filters out read-only transactions and 
    34   updates to tables that are not of interest.</para></listitem> 
    35  
    36   <listitem><para> If some disaster strikes, you can look at the logs 
    37   of queries in detail</para> 
    38  
    39   <para> This makes log shipping potentially useful even though you 
    40   might not intend to actually create a log-shipped 
    41   node.</para></listitem> 
    42  
    43   <listitem><para> This is a really slick scheme for building load for 
    44   doing tests</para></listitem> 
    45  
    46   <listitem><para> We have a data <quote>escrow</quote> system that 
    47   would become incredibly cheaper given log shipping</para></listitem> 
    48  
    49   <listitem><para> You may apply triggers on the <quote>disconnected 
    50   node </quote> to do additional processing on the data</para> 
    51  
    52   <para> For instance, you might take a fairly <quote>stateful</quote> 
    53   database and turn it into a <quote>temporal</quote> one by use of 
    54   triggers that implement the techniques described in 
     26  <listitem><para> Répliquer des noeuds qui   
     27  <emphasis>ne peuvent pas</emphasis> être securisés;</para></listitem> 
     28 
     29  <listitem><para> Répliquer dans des lieux ou il n'est pas possible 
     30      d'établir des communications bidirectionnelles;</para></listitem> 
     31 
     32  <listitem><para> Utiliser une nouvelle forme de <acronym>PITR</acronym> 
     33  (Point In Time Recovery) qui filtre les transactions composées uniquement 
     34  de lectures et celles qui mettent à jour des tables qui ne sont pas  
     35  intéressantes;</para></listitem> 
     36 
     37  <listitem><para> En cas de désastre, vous pouvez regarder à l'intérieur  
     38      des logs pour voir le détail des requêtes;</para> 
     39 
     40  <para> Cela rend le log shipping potentiellement utile même si  
     41    vous n'avez pas réellement l'intention de créer un noeud répliqué; 
     42    </para></listitem> 
     43 
     44  <listitem><para> C'est un méthode trÚs subtile pour charger  
     45      des données en vue de tests; 
     46      </para></listitem> 
     47 
     48  <listitem><para> Nous avons un systÚme <quote>escrow</quote> qui 
     49      serait incroyablement moins cher avec du log shipping;</para></listitem> 
     50 
     51  <listitem><para> Vous pouvez appliquer des triggers sur un  
     52      <quote>noeud déconnecté</quote> pour effectuer des traitements 
     53      supplémentaires sur les données.</para> 
     54 
     55  <para> Par exemple, vous pouvez prendre une base relativement <quote>statique</quote> 
     56  et la transformer en une table <quote>temporelle</quote> , en utilisant 
     57  des triggers qui that implémentent les techniques décrites dans 
    5558  <citation>Developing Time-Oriented Database Applications in SQL 
    56   </citation> by <ulink url="http://www.cs.arizona.edu/people/rts/"> 
     59  </citation> de <ulink url="http://www.cs.arizona.edu/people/rts/"> 
    5760  Richard T. Snodgrass</ulink>.</para></listitem> 
    5861 
    …… 
    6265<qandaentry> 
    6366 
    64 <question> <para> Where are the <quote>spool files</quote> for a 
    65 subscription set generated?</para> 
     67<question> <para> Où sont générés les <quote>fichiers de log</quote> d'un  
     68    ensemble de réplication donné ?</para> 
    6669</question> 
    6770 
    68 <answer> <para> Any <link linkend="slon"> slon </link> subscriber node 
    69 can generate them by adding the <option>-a</option> option.</para> 
    70  
    71 <note><para> Notice that this implies that in order to use log 
    72 shipping, you must have at least one subscriber node. </para></note> 
     71<answer> <para> Chaque noeud abonné <link linkend="slon"> slon </link> 
     72    peut les générer en ajoutant l'option <option>-a</option>.</para> 
     73 
     74<note><para> Notez que cela implique que pour utiliser le log 
     75shipping, vous devez avoir au moins un noeud abonné. </para></note> 
    7376</answer> 
    7477 
    7578</qandaentry> 
    7679 
    77 <qandaentry> <question> <para> What takes place when a <xref 
    78 linkend="stmtfailover"/>/ <xref linkend="stmtmoveset"/> takes 
    79 place?</para></question> 
    80  
    81 <answer><para> Nothing special.  So long as the archiving node remains 
    82 a subscriber, it will continue to generate logs.</para></answer> 
    83  
    84 <answer> <warning> <para>If the archiving node becomes the origin, on 
    85 the other hand, it will continue to generate logs.</para> </warning></answer> 
     80<qandaentry> <question> <para> Que se passe-t-il lors d'un <xref 
     81linkend="stmtfailover"/>/ <xref linkend="stmtmoveset"/>  
     82 se déclenche ?</para></question> 
     83 
     84<answer><para> Rien de spécial. Tant que le noeud d'archivage rester un abonné 
     85    il continue à produire des logs.</para></answer> 
     86 
     87<answer> <warning> <para>Si le noeud d'archivage devient l'origine, il  
     88      continuera à produire des logs.</para> </warning></answer> 
    8689</qandaentry> 
    8790 
    88 <qandaentry> <question> <para> What if we run out of <quote>spool 
    89 space</quote>?  </para></question> 
    90  
    91 <answer><para> The node will stop accepting <command>SYNC</command>s 
    92 until this problem is alleviated.  The database being subscribed to 
    93 will also fall behind. </para></answer> 
     91<qandaentry> <question> <para> Que se passe-t-il lorsqu'il n'y a plus assez d'espace  
     92      pour les fichiers de logs ?  </para></question> 
     93 
     94<answer><para> Le noeud n'accepte plus les événements <command>SYNC</command>s 
     95jusqu'à ce que le problÚme soit réglé. La base de donnée qui est dupliquée  
     96tombera également en panne. </para></answer> 
    9497</qandaentry> 
    9598 
    9699<qandaentry> 
    97 <question> <para> How do we set up a subscription?  </para></question> 
    98  
    99 <answer><para> The script in <filename>tools</filename> called 
    100 <application>slony1_dump.sh</application> is a shell script that dumps 
    101 the <quote>present</quote> state of the subscriber node.</para> 
    102  
    103 <para> You need to start the <application><link linkend="slon"> slon 
    104 </link></application> for the subscriber node with logging turned on. 
    105 At any point after that, you can run 
    106 <application>slony1_dump.sh</application>, which will pull the state 
    107 of that subscriber as of some <command>SYNC</command> event.  Once the 
    108 dump completes, all the <command>SYNC</command> logs generated from 
    109 the time that dump <emphasis>started</emphasis> may be added to the 
    110 dump in order to get a <quote>log shipping subscriber.</quote> 
     100<question> <para> Comment réaliser un abonnement ?  </para></question> 
     101 
     102<answer><para> Le script dans <filename>tools</filename> nommé 
     103<application>slony1_dump.sh</application> est un script shell qui  
     104exporte l'état <quote>actuel</quote> du noeud abonné.</para> 
     105 
     106<para> Vous devez lancer le <application><link linkend="slon"> slon 
     107</link></application> pour le noeud abonné avec log shipping activé. 
     108À tout moment, vous pouvez lancer la commande  
     109<application>slony1_dump.sh</application>, qui va récupérer l'état  
     110de l'abonné sous la forme d'événements <command>SYNC</command>. 
     111Une fois que l'export est complet, tous les logs <command>SYNC</command>  
     112produits à partir du moment où l'export a <emphasis>démarré</emphasis> 
     113seront ajoutés à l'export afin d'obtenir un <quote>noeud abonné  
     114  au log shipping</quote>. 
    111115</para></answer> 
    112116</qandaentry> 
    113117 
    114 <qandaentry> <question><para> What are the limitations of log 
    115 shipping? </para> 
     118<qandaentry> <question><para> Quelles sont les limitations du log 
     119shipping ? </para> 
    116120</question> 
    117121 
    118 <answer><para> In the initial release, there are rather a lot of 
    119 limitations.  As releases progress, hopefully some of these 
    120 limitations may be alleviated/eliminated. </para> </answer> 
    121  
    122 <answer><para> The log shipping functionality amounts to 
    123 <quote>sniffing</quote> the data applied at a particular subscriber 
    124 node.  As a result, you must have at least one <quote>regular</quote> 
    125 node; you cannot have a cluster that consists solely of an origin and 
    126 a set of <quote>log shipping nodes.</quote>. </para></answer> 
    127  
    128 <answer><para> The <quote>log shipping node</quote> tracks the 
    129 entirety of the traffic going to a subscriber.  You cannot separate 
    130 things out if there are multiple replication sets.  </para></answer> 
    131  
    132 <answer><para> The <quote>log shipping node</quote> presently only 
    133 fully tracks <command>SYNC</command> events.  This should be 
    134 sufficient to cope with <emphasis>some</emphasis> changes in cluster 
    135 configuration, but not others.  </para> 
    136  
    137 <para> A number of event types <emphasis> are </emphasis> handled in 
    138 such a way that log shipping copes with them: 
    139  
    140 <itemizedlist> 
    141  
    142 <listitem><para><command>SYNC </command> events are, of course, 
    143 handled.</para></listitem> 
    144  
    145 <listitem><para><command>DDL_SCRIPT</command> is handled.</para></listitem> 
     122<answer><para> Dans la version initiale, il y a beaucoup de limitations. 
     123    Heureusement au fur et à mesure des nouvelles versions, certaines de ces  
     124    limitations ont été corrigées ou supprimées. </para> </answer> 
     125 
     126<answer><para> La fonctionnalité du log shipping revient à  
     127<quote>sniffer</quote> les données appliquées sur un noeud abonné 
     128. En conséquence, vous devez avoir au moins un noeud  
     129 <quote>standard</quote>; vous ne pouvez pas avoir un cluster composé 
     130 seulement d'une origine et d'un ensemble de <quote>noeuds de log shipping 
     131 </quote>. </para></answer> 
     132 
     133<answer><para> Le <quote>noeud de log shipping</quote> traque 
     134    la totalité du trafic allant vers un abonné. Vous pouvez 
     135    séparer les choses lorsqu'il y a de multiple ensembles de  
     136    réplication. </para></answer> 
     137 
     138<answer><para> Actuellement le <quote>noeud de log shipping </quote> 
     139    traque uniquement les événements <command>SYNC</command>. 
     140    Cela devrait être suffisant pour gérer <emphasis>certains</emphasis> 
     141    changements de la configuration du cluster, mais pas tous. 
     142 </para> 
     143 
     144<para> Un bonne partie des types événements <emphasis> sont </emphasis>  
     145  gérés afin que le log shipping puissent les traités : 
     146 
     147<itemizedlist> 
     148 
     149<listitem><para>Bien évidemment, les événements <command>SYNC </command> sont gérés; 
     150    </para></listitem> 
     151 
     152<listitem><para>Les <command>DDL_SCRIPT</command> sont gérés.</para></listitem> 
    146153 
    147154<listitem><para><command> UNSUBSCRIBE_SET </command></para>  
    148155 
    149 <para> This event, much like <command>SUBSCRIBE_SET</command> is not 
    150 handled by the log shipping code.  But its effect is, namely that 
    151 <command>SYNC</command> events on the subscriber node will no longer 
    152 contain updates to the set.</para> 
    153  
    154 <para> Similarly, <command>SET_DROP_TABLE</command>, 
     156<para> Cet événement, tout comme <command>SUBSCRIBE_SET</command> n'est pas 
     157  géré par le noeud de log shipping.  Mais cette commande, par définition, 
     158  implique que les événements <command>SYNC</command> ne 
     159  contiennent plus de mises à jour pour l'ensemble de réplication; 
     160  </para> 
     161 
     162<para> De la même façon, <command>SET_DROP_TABLE</command>, 
    155163<command>SET_DROP_SEQUENCE</command>, 
    156164<command>SET_MOVE_TABLE</command>, 
    157165<command>SET_MOVE_SEQUENCE</command> <command>DROP_SET</command>, 
    158 <command>MERGE_SET</command>, will be handled 
    159 <quote>appropriately</quote>.</para></listitem> 
     166<command>MERGE_SET</command>, seront géré de maniÚre <quote>appropriée 
     167</quote>;</para></listitem> 
    160168 
    161169<listitem><para><command> SUBSCRIBE_SET </command></para> 
    162170 
    163 <para> Unfortunately, there is some <quote>strangeness</quote> in the 
    164 handling of this...  When <command>SUBSCRIBE_SET</command> occurs, it 
    165 leads to an event being raised, and processed, <emphasis>purely on the 
    166 subscriber</emphasis>, called <command>ENABLE_SUBSCRIPTION</command>.</para> 
    167  
    168 <para> <command> SUBSCRIBE_SET </command> is really quite a simple 
    169 event; it merely <emphasis>declares</emphasis> that a node is 
    170 subscribing to a particular set via a particular provider.  <emphasis> 
    171 It doesn't copy data!</emphasis> </para> 
    172  
    173 <para> The meat of the subscription work is done by 
    174 <command>ENABLE_SUBSCRIPTION</command>, which is an event that is 
    175 raised on the local node, not in the same sequence as the other events 
    176 coming from other nodes (notably the data provider). </para> 
    177  
    178 <para> With revisions in sequencing of logs that took place in 1.2.11, 
    179 this now presents no problem for the user.</para> 
     171<para> Malheureusement, des choses <quote>étranges</quote> lorsqu'on 
     172  gÚre cette commande... Quand un <command>SUBSCRIBE_SET</command> 
     173  se produit, cela déclenche un évÚnement nommé  
     174  <command>ENABLE_SUBSCRIPTION</command> 
     175  qui est levé et traiter uniquement sur le noeud abonné;</para> 
     176 
     177<para> <command> SUBSCRIBE_SET </command> est vraiment un événement 
     178  trÚs simple, il se contente de <emphasis>déclarer</emphasis>  
     179  qu'un noeud s'abonne à un ensemble donné via un fournisseur donné. 
     180   <emphasis>Il ne copie pas les données !</emphasis> </para> 
     181 
     182<para> Le coeur du travail de souscription est réalisé par  
     183<command>ENABLE_SUBSCRIPTION</command>, qui est un événement 
     184déclenché sur le noeud local, et non pas dans la même séquence 
     185que les autres événements en provenance des autres noeuds ( notament 
     186le fournisseur de données ). </para> 
     187 
     188<para> Avec la modifications du traitement des logs intervenus dans la version 1.2.11, 
     189ceci ne présente plus de problÚmes pour l'utilisateur.</para> 
    180190 
    181191</listitem>  
    182192 
    183 <listitem><para> The various events involved in node configuration are 
    184 irrelevant to log shipping: 
     193<listitem><para> Les différents événements impliqués dans la configuration d'un  
     194    noeud sont inutiles dans le cadre du log shipping : 
    185195 
    186196<command>STORE_NODE</command>, 
    …… 
    192202<command>DROP_LISTEN</command></para></listitem> 
    193203 
    194 <listitem><para> Events involved in describing how particular sets are 
    195 to be initially configured are similarly irrelevant: 
     204<listitem><para> Les événements impliqués dans la configuration 
     205    des ensembles de réplication sont également inutiles : 
    196206 
    197207<command>STORE_SET</command>, 
    …… 
    207217</answer> 
    208218 
    209 <answer><para> It would be nice to be able to turn a <quote>log 
    210 shipped</quote> node into a fully communicating &slony1; node that you 
    211 could failover to.  This would be quite useful if you were trying to 
    212 construct a cluster of (say) 6 nodes; you could start by creating one 
    213 subscriber, and then use log shipping to populate the other 4 in 
    214 parallel.</para> 
    215  
    216 <para> This usage is not supported, but presumably one could add the 
    217 &slony1; configuration to the node, and promote it into being a new 
    218 node.  Again, a Simple Matter Of Programming (that might not 
    219 necessarily be all that simple)... </para></answer> 
     219<answer><para> Il serait pratique de transformer un noeud de  <quote>log 
     220shipping</quote> est un noeud &slony1; complÚtement fonctionnel sur  
     221lequel on pourrait basculer. Cela serait utile   
     222(par exemple) pour un cluster de 6 noeuds; cela permettrait de  
     223commencer par créer noeud abonné puis d'utiliser le log shipping 
     224pour construire les 4 autres noeuds en parallÚle. 
     225</para> 
     226 
     227<para> Cette utilisation n'est pas possible, mais on peut  ajouter 
     228  la configuration &slony1; dans un noeud, et le promouvoir  
     229  en tant que nouveau noeud.  
     230  Encore une fois, c'est une simple question de programmation 
     231  (mais ça n'est pas forcément si simple)... </para></answer> 
    220232</qandaentry> 
    221233</qandaset> 
    222234 
    223 <sect2><title> Usage Hints </title> 
    224  
    225 <note> <para> Here are some more-or-less disorganized notes about how 
    226 you might want to use log shipping...</para> </note> 
    227  
    228 <itemizedlist> 
    229  
    230 <listitem><para> You <emphasis>don't</emphasis> want to blindly apply 
    231 <command>SYNC</command> files because any given 
    232 <command>SYNC</command> file may <emphasis>not</emphasis> be the right 
    233 one.  If it's wrong, then the result will be that the call to 
    234 <function> setsyncTracking_offline() </function> will fail, and your 
    235 <application> psql</application> session will <command> ABORT 
    236 </command>, and then run through the remainder of that 
    237 <command>SYNC</command> file looking for a <command>COMMIT</command> 
    238 or <command>ROLLBACK</command> so that it can try to move on to the 
    239 next transaction.</para> 
    240  
    241 <para> But we <emphasis> know </emphasis> that the entire remainder of 
    242 the file will fail!  It is futile to go through the parsing effort of 
    243 reading the remainder of the file.</para> 
    244  
    245 <para> Better idea:  
    246  
    247 <itemizedlist> 
    248  
    249 <listitem><para> Read the first few lines of the file, up to and 
    250 including the <function> setsyncTracking_offline() </function> 
    251 call.</para></listitem> 
    252  
    253 <listitem><para> Try to apply it that far.</para></listitem> 
    254  
    255 <listitem><para> If that failed, then it is futile to continue; 
    256 <command>ROLLBACK</command> the transaction, and perhaps consider 
    257 trying the next file.</para></listitem> 
    258  
    259 <listitem><para> If the <function> setsyncTracking_offline() 
    260 </function> call succeeds, then you have the right next 
    261 <command>SYNC</command> file, and should apply it.  You should 
    262 probably <command>ROLLBACK</command> the transaction, and then use 
    263 <application>psql</application> to apply the entire file full of 
    264 updates.</para></listitem> 
     235<sect2><title> Conseils d'utilisation </title> 
     236 
     237<note> <para> Voici quelques notes plus ou moins structurées 
     238    sur l'utilisation idéale du log shipping...</para> </note> 
     239 
     240<itemizedlist> 
     241 
     242<listitem><para> Vous ne  <emphasis>devez</emphasis> pas appliquer aveuglément 
     243    les fichiers <command>SYNC</command> car on en peut pas prendre un 
     244    fichier <command>SYNC</command> au hasard.  
     245    Si ce n'est pas un fichier approprié, alors la  
     246    commande <function> setsyncTracking_offline() </function>  
     247    échouera et votre session <application> psql</application> 
     248    recevra la commande <command> ABORT</command>, puis recherchera  
     249    dans le fichier <command>SYNC</command> à la recherche d'un  
     250    <command>COMMIT</command> ou d'un <command>ROLLBACK</command> afin  
     251    de continuer vers la prochaine transaction.</para> 
     252 
     253<para> Mais nous <emphasis> savons </emphasis> que la totalité du  
     254  contenu du fichier va échouer ! Il est futile de continuer à analyser 
     255  le reste du fichier.</para> 
     256 
     257<para> Voici une meilleure idée :  
     258 
     259<itemizedlist> 
     260 
     261<listitem><para> Tout d'abord, Lire les premiÚres lignes du fichier, jusqu'à  
     262    l'appel à la fonction <function> setsyncTracking_offline() </function>. 
     263  </para></listitem> 
     264 
     265<listitem><para> Essayez de l'appliquer jusque là.</para></listitem> 
     266 
     267<listitem><para> Si cela échoue, alors il est futile de continuer; 
     268lancez un <command>ROLLBACK</command> sur la transaction, et essayez 
     269éventuellement un autre fichier.</para></listitem> 
     270 
     271<listitem><para> Si l'appel à <function> setsyncTracking_offline() 
     272</function> fonctionne, alors vous avez trouver le bon fichier de  
     273<command>SYNC</command> et vous pouvez l'appliquer.  Vous devrez  
     274probablement faire un <command>ROLLBACK</command> sur la transaction, 
     275puis utiliser <application>psql</application> pour appliquer 
     276la totalité des mises à jours contenues dans le fichier. 
     277</para></listitem> 
    265278 
    266279</itemizedlist></para> 
    267280 
    268 <para> In order to support the approach of grabbing just the first few 
    269 lines of the sync file, the format has been set up to have a line of 
    270 dashes at the end of the <quote>header</quote> material: 
     281<para> Afin de faciliter la récupération des premiÚres lignes 
     282  des fichiers sync, le format a été conçu pour qu'une ligne 
     283  de pointillée indique la fin de <quote>l'en-tête </quote> : 
    271284 
    272285<programlisting> 
    …… 
    280293 
    281294 
    282 <listitem><para> Note that the header includes a timestamp indicating 
    283 SYNC time.  
     295<listitem><para> Notez que l'en-tête inclut le timestamp qui témoigne de la  
     296    date de l'événement SYNC.  
    284297<programlisting> 
    285298-- Slony-I log shipping archive 
    …… 
    291304</programlisting></para> 
    292305 
    293 <para> This timestamp represents the time at which the 
    294 <command>SYNC</command> was issued on the origin node.</para> 
    295  
    296 <para> The value is stored in the log shipping configuration table 
     306<para> Ce timestamp représente la date où le <command>SYNC</command> 
     307  a été déclenché sur le noeud d'origine.</para> 
     308 
     309<para> La valeur est stockée dans la table de configuration  
    297310sl_setsync_offline.</para> 
    298311 
    299 <para> If you are constructing a temporal database, this is likely to 
    300 represent the time you will wish to have apply to all of the data in 
    301 the given log shipping transaction log. </para> 
    302 </listitem> 
    303  
    304 <listitem><para> You may find information on how relevant activity is 
    305 logged in <xref linkend="logshiplog"/>. </para></listitem> 
    306  
    307 </itemizedlist> 
    308  
    309 <para> As of 1.2.11, there is an <emphasis>even better idea</emphasis> 
    310 for application of logs, as the sequencing of their names becomes more 
    311 predictable.</para> 
    312  
    313 <itemizedlist> 
    314  
    315 <listitem><para> The table, on the log shipped node, tracks which log 
    316 it most recently applied in table 
    317 <envar>sl_archive_tracking</envar>. </para> 
    318  
    319 <para> Thus, you may predict the ID number of the next file by taking 
    320 the latest counter from this table and adding 1.</para> 
    321 </listitem> 
    322  
    323 <listitem><para> There is still variation as to the filename, 
    324 depending on what the overall set of nodes in the cluster are.  All 
    325 nodes periodically generate <command>SYNC</command> events, even if 
    326 they are not an origin node, and the log shipping system does generate 
    327 logs for such events. </para> 
    328  
    329 <para> As a result, when searching for the next file, it is necessary 
    330 to search for files in a manner similar to the following: 
     312<para> Si vous construisez une base dynamique, cela représente probablement 
     313  le moment ou voudrez appliquer toute les données d'une tansaction de  
     314  de log shipping. </para> 
     315</listitem> 
     316 
     317<listitem><para> Vous pouvez trouver plus d'information sur  
     318    comment l'activité du noeud est enregistré dans  
     319    <xref linkend="logshiplog"/>. </para></listitem> 
     320 
     321</itemizedlist> 
     322 
     323<para> À partir de la version 1.2.11, il existe une méthode  
     324  <emphasis>encore meilleure</emphasis> pour appliquer les logs, car  
     325  leu rÚgle de nommage est devenu plus compréhensible.</para> 
     326 
     327<itemizedlist> 
     328 
     329<listitem><para> Les traces, sur le noeud de log shipping, qui 
     330    indiquent quel est quel est le log le plus récemment  
     331    traité, sont stockées dans la table <envar>sl_archive_tracking</envar>. </para> 
     332 
     333<para> Ainsi, vous pouvez prédire l'identifiant du prochain 
     334  fichier de log en incrémentant le dernier identifiant de cette 
     335  table.</para> 
     336</listitem> 
     337 
     338<listitem><para> Il existe néanmoins des variations dans le  
     339    nommage des fichiers, en fonction du nombre de noeuds 
     340    qui composent le cluster. Tous les noeuds produisent  
     341    réguliÚrement des événements <command>SYNC</command>, 
     342    même si ils ne sont pas le noeud origine, et le systÚme 
     343    de log shipping génÚre des logs pour ces événements. </para> 
     344 
     345<para> En conséquence, lorsque l'on cherche le fichier de log suivant, 
     346  il est nécessaire de chercher de maniÚre suivante : 
    331347 
    332348<programlisting> 
    333349ARCHIVEDIR=/var/spool/slony/archivelogs/node4 
    334 SLONYCLUSTER=mycluster 
     350SLONYCLUSTER=mon_cluster 
    335351PGDATABASE=logshipdb 
    336352PGHOST=logshiphost 
    …… 
    353369</application> </title> 
    354370 
    355 <indexterm><primary> trigger deactivation </primary> </indexterm> 
    356  
    357 <para> It was once pointed out (<ulink 
    358 url="http://www.slony.info/bugzilla/show_bug.cgi?id=19"> Bugzilla bug 
    359 #19</ulink>) that the dump of a schema may include triggers and rules 
    360 that you may not wish to have running on the log shipped node.</para> 
    361  
    362 <para> The tool <filename> tools/find-triggers-to-deactivate.sh 
    363 </filename> was created to assist with this task.  It may be run 
    364 against the node that is to be used as a schema source, and it will 
    365 list the rules and triggers present on that node that may, in turn 
    366 need to be deactivated.</para> 
    367  
    368 <para> It includes <function>logtrigger</function> and <function>denyaccess</function> 
    369 triggers which will may be left out of the extracted schema, but it is 
    370 still worth the Gentle Administrator verifying that such triggers are 
    371 kept out of the log shipped replica.</para> 
     371<indexterm><primary> Désactivation des triggers </primary> </indexterm> 
     372 
     373<para> Le <ulink 
     374url="http://www.slony.info/bugzilla/show_bug.cgi?id=19"> bug 
     375#19</ulink> indique que le dump d'un schéma peut contenir des 
     376triggers et des rÚgles que l'on ne souhaite pas activer sur un  
     377noeud de log shipping.</para> 
     378 
     379<para> L'outil <filename> tools/find-triggers-to-deactivate.sh 
     380</filename> a été créé pour assister l'utilisateur dans cette tache. 
     381Il peut être lancé sur un noeud qui sera utilisé comme schéma source, 
     382et il liste les rÚgles et les triggers présents sur ce noeud qui devraient 
     383être désactivés.</para> 
     384 
     385<para> Cela comprend le triggers <function>logtrigger</function>  
     386  et <function>denyaccess</function> qui sont normalement exclut 
     387  du schéma extrait avec pgdump. Il est toutefois de la responsabilité 
     388  de l'administrateur de vérifier que des triggers comme ceux-ci 
     389  sont bien retirés du réplicat du log shipping. 
     390  </para> 
    372391 
    373392</sect2> 
    374393 
    375 <sect2> <title> <application>slony_logshipper </application> Tool </title> 
    376  
    377  
    378 <para> As of version 1.2.12, &slony1; has a tool designed to help 
    379 apply logs, called <application>slony_logshipper</application>.  It is 
    380 run with three sorts of parameters:</para> 
    381  
    382 <itemizedlist> 
    383 <listitem><para> Options, chosen from the following: </para>  
    384 <itemizedlist> 
    385 <listitem><para><option>h</option> </para> <para>    display this help text and exit </para> </listitem> 
    386 <listitem><para><option>v</option> </para> <para>    display program version and exit </para> </listitem> 
    387 <listitem><para><option>q</option> </para> <para>    quiet mode </para> </listitem> 
    388 <listitem><para><option>l</option> </para> <para>    cause running daemon to reopen its logfile </para> </listitem> 
    389 <listitem><para><option>r</option> </para> <para>    cause running daemon to resume after error </para> </listitem> 
    390 <listitem><para><option>t</option> </para> <para>    cause running daemon to enter smart shutdown mode </para> </listitem> 
    391 <listitem><para><option>T</option> </para> <para>    cause running daemon to enter immediate shutdown mode </para> </listitem> 
    392 <listitem><para><option>c</option> </para> <para>    destroy existing semaphore set and message queue            (use with caution) </para> </listitem> 
    393 <listitem><para><option>f</option> </para> <para>    stay in foreground (don't daemonize) </para> </listitem> 
    394 <listitem><para><option>w</option> </para> <para>    enter smart shutdown mode immediately </para> </listitem> 
    395 </itemizedlist> 
    396 </listitem> 
    397 <listitem><para> A specified log shipper configuration file </para> 
    398 <para> This configuration file consists of the following specifications:</para> 
     394<sect2> <title> L'outil <application>slony_logshipper </application></title> 
     395 
     396 
     397<para> À partir de la version 1.2.12, &slony1; a un outil conçu pour 
     398  aider à appliquer les logs, nommé <application>slony_logshipper</application>. 
     399  Il fonctionne avec trois types de paramÚtres : 
     400</para> 
     401 
     402<itemizedlist> 
     403<listitem><para> des options : </para>  
     404<itemizedlist> 
     405<listitem><para><option>h</option> </para> <para>    affiche cette aide et se termine </para> </listitem> 
     406<listitem><para><option>v</option> </para> <para>    affiche la version et se termine </para> </listitem> 
     407<listitem><para><option>q</option> </para> <para>    mode silencieux </para> </listitem> 
     408<listitem><para><option>l</option> </para> <para>    ordonne au démon de rouvrir le fichier </para> </listitem> 
     409<listitem><para><option>r</option> </para> <para>    ordonne au démon de continuer aprÚs une erreur </para> </listitem> 
     410<listitem><para><option>t</option> </para> <para>    ordonne au démon d'entrer en mode d'arrêt intelligent ("smart shutdown") </para> </listitem> 
     411<listitem><para><option>T</option> </para> <para>    ordonne au démon d'entrer en mode d'arrêt immédiat </para> </listitem> 
     412<listitem><para><option>c</option> </para> <para>    détruit les sémaphores existantes et la file d'attente des messages  (utiliser avec précaution) </para> </listitem> 
     413<listitem><para><option>f</option> </para> <para>    rester au premier plan (ne pas fonctionner en mode démon) </para> </listitem> 
     414<listitem><para><option>w</option> </para> <para>    entrer immédiatement en mode d'arrêt intelligent</para> </listitem> 
     415</itemizedlist> 
     416</listitem> 
     417<listitem><para> un fichier de configuration spécifique </para> 
     418<para> Ce fichier est composé des paramÚtres suivants :</para> 
    399419<itemizedlist> 
    400420<listitem><para> <command>logfile = './offline_logs/logshipper.log';</command></para>  
    401 <para> Where the log shipper will leave messages.</para> </listitem> 
    402 <listitem><para> <command>cluster name = 'T1';</command></para> <para> Cluster name </para> </listitem> 
    403 <listitem><para> <command>destination database  = 'dbname=slony_test3';</command></para> <para> Optional conninfo for the destination database.  If given, the log shipper will connect to thisdatabase, and apply logs to it. </para> </listitem> 
    404 <listitem><para> <command>archive dir = './offline_logs';</command></para> <para>The archive directory is required when running in <quote>database-connected</quote> mode to have a place to scan for missing (unapplied) archives. </para> </listitem> 
    405 <listitem><para> <command>destination dir = './offline_result';</command></para> <para> If specified, the log shipper will write the results of data massaging into result logfiles in this directory.</para> </listitem> 
    406 <listitem><para> <command>max archives = 3600;</command></para> <para> This fights eventual resource leakage; the daemon will enter <quote>smart shutdown</quote> mode automatically after processing this many archives. </para> </listitem> 
    407 <listitem><para> <command>ignore table "public"."history";</command></para> <para> One may filter out single tables  from log shipped replication </para> </listitem> 
    408 <listitem><para> <command>ignore namespace "public";</command></para> <para> One may filter out entire namespaces  from log shipped replication </para> </listitem> 
    409 <listitem><para> <command>rename namespace "public"."history" to "site_001"."history";</command></para> <para> One may rename specific tables.</para> </listitem> 
    410 <listitem><para> <command>rename namespace "public" to "site_001";</command></para> <para> One may rename entire namespaces.</para> </listitem> 
    411 <listitem><para> <command>post processing command = 'gzip -9 $inarchive';</command></para> <para> Pre- and post-processign commands are executed via <function>system(3)</function>. </para> </listitem> 
    412 </itemizedlist> 
    413 <para> An <quote>@</quote> as the first character causes the exit code to be ignored.  Otherwise, a nonzero exit code is treated as an error and causes processing to abort. </para> 
    414  
    415 <para> Pre- and post-processing commands have two further special variables defined: </para> 
    416 <itemizedlist> 
    417 <listitem><para> <envar>$inarchive</envar>  - indicating incoming archive filename </para> </listitem> 
    418 <listitem><para> <envar>$outnarchive</envar>  - indicating outgoing archive filename </para> </listitem> 
     421<para> L'endroit où le log shipper laissera ses traces d'exécutions.</para> </listitem> 
     422<listitem><para> <command>cluster name = 'T1';</command></para> <para> le nom du cluster </para> </listitem> 
     423<listitem><para> <command>destination database  = 'dbname=slony_test3';</command></para> <para> Le paramÚtre conninfo  
     424    optionnel pour se connecter à la base destination. Si ce paramÚtre est fourni, 
     425    le log shipper se connectera à cette base et y appliquera les logs. </para> </listitem> 
     426<listitem><para> <command>archive dir = './offline_logs';</command></para> <para> Le répertoire d'archive  
     427    est obligatoire lorsqu'on est en mode <quote>connecté à une database</quote> afin de pouvoir 
     428    scanner noeud à la recherche d'archives manquantes (ou non appliquées). </para> </listitem> 
     429<listitem><para> <command>destination dir = './offline_result';</command></para> <para> Si ce paramÚtre est défini, 
     430    le log shipper écrira les résultats du traitement des données à l'intérieur de fichiers 
     431    de log placés dans ce répertoire.</para> </listitem> 
     432<listitem><para> <command>max archives = 3600;</command></para> <para> Ce paramÚtre lutte 
     433    contre d'éventuelles fuites mémoire; le démon entrera en mode d'arrêt intelligent( <quote>smart shutdown</quote> )  
     434    automatiquement aprÚs avoir traiter ce nombre d'archives. </para> </listitem> 
     435<listitem><para> <command>ignore table "public"."history";</command></para> <para> On peut exclure 
     436    certaines tables du systÚme de log shipping</para> </listitem> 
     437<listitem><para> <command>ignore namespace "public";</command></para> <para> On peut exclure 
     438    un espace de noms du systÚme de réplication </para> </listitem> 
     439<listitem><para> <command>rename namespace "public"."history" to "site_001"."history";</command></para> <para> 
     440    On peut renommer des tables spécifiques.</para> </listitem> 
     441<listitem><para> <command>rename namespace "public" to "site_001";</command></para> <para>  
     442    On peut renommer un espace de noms.</para> </listitem> 
     443<listitem><para> <command>post processing command = 'gzip -9 $inarchive';</command></para> <para>  
     444    Les commandes de pré-traitement et post-traitement sont exécutées via la fonction <function>system(3)</function>. </para> </listitem> 
     445</itemizedlist> 
     446<para> Un <quote>@</quote> placé devant le nom de la commande permet d'ignorer un code de retour. Sinon, tout code 
     447  de retour différent de zéro sera traité comme une erreur et provoquera l'arrêt du processus. </para> 
     448 
     449<para> Par ailleurs les commandes de pré-traitement et de post-traitement ont accÚs à deux variables spéciales : </para> 
     450<itemizedlist> 
     451<listitem><para> <envar>$inarchive</envar>  - indique le nom du fichier d'archive en entrée </para> </listitem> 
     452<listitem><para> <envar>$outnarchive</envar>  - indique le nom du fichier d'archive en sortie </para> </listitem> 
    419453</itemizedlist> 
    420454</listitem> 
    …… 
    424458-s "Slony log shipping failed" postgres@localhost ';</command></para> 
    425459 
    426 <para>  The error command indicates a command to execute upon encountering an error.  All logging since the last successful completion of an archive is available in the <envar>$errortext</envar> variable. </para>  
    427  
    428 <para> In the example shown, this sends an email to the DBAs upon 
    429 encountering an error.</para> </listitem> 
    430 </itemizedlist> 
    431  
    432 <itemizedlist> 
    433 <listitem><para> Archive File Names</para> 
    434  
    435 <para> Each filename is added to the SystemV Message queue for 
    436 processing by a <application>slony_logshipper</application> 
    437 process. </para> 
     460<para>  Le commande d'erreur indique quelle commande lancé lorsqu'une erreur est rencontrée. 
     461  Toutes l'archivage réalisée depuis le dernier archive traité avec succÚs est disponible 
     462  dans la variable <envar>$errortext</envar>. </para>  
     463 
     464<para> Dans l'exemple donné, un courriel est envoyé à l'administrateur 
     465  lorsqu'une erreur est rencontrée.</para> </listitem> 
     466</itemizedlist> 
     467 
     468<itemizedlist> 
     469<listitem><para> Noms des fichiers d'archive</para> 
     470 
     471<para> Chaque nom de fichier est ajouté à la file d'attente des messages SystemV 
     472  afin qu'un processus <application>slony_logshipper</application> le traite.</para> 
    438473 
    439474</listitem>