root/traduc/trunk/slony/logshipping.xml

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

<sect1 id="logshipping">
<title>Log Shipping</title>
<indexterm><primary>log shipping</primary></indexterm>

<para> Une des nouvelles fonctionnalités de la version 1.1, qui 
  ne fut réellement stable qu'à partir de la version 1.2.11, 
  est la possibilité de regrouper les mises à jour dans des fichiers
  de logs qui sont stockés dans un répertoire d'attente.
  </para>

<para> Ces fichiers de log peuvent alors être transférés selon la
  méthode de votre choix vers le <quote>serveur esclave</quote>,
  que ce soit via   FTP, rsync, ou même avec une <quote>clé USB</quote> 
  d' 1GB transportée par avion.</para>

<para> Il y a plein de choses sympas à faire avec un tel flux de donnée,
  en particulier :
<itemizedlist>
  
  <listitem><para> Répliquer des noeuds qui  
  <emphasis>ne peuvent pas</emphasis> être securisés;</para></listitem>

  <listitem><para> Répliquer dans des lieux ou il n'est pas possible
      d'établir des communications bidirectionnelles;</para></listitem>

  <listitem><para> Utiliser une nouvelle forme de <acronym>PITR</acronym>
  (Point In Time Recovery) qui filtre les transactions composées uniquement
  de lectures et celles qui mettent à jour des tables qui ne sont pas 
  intéressantes;</para></listitem>

  <listitem><para> En cas de désastre, vous pouvez regarder à l'intérieur 
      des logs pour voir le détail des requêtes;</para>

  <para> Cela rend le log shipping potentiellement utile même si 
    vous n'avez pas réellement l'intention de créer un noeud répliqué;
    </para></listitem>

  <listitem><para> C'est un méthode trÚs subtile pour charger 
      des données en vue de tests;
      </para></listitem>

  <listitem><para> Nous avons un systÚme <quote>escrow</quote> qui
      serait incroyablement moins cher avec du log shipping;</para></listitem>

  <listitem><para> Vous pouvez appliquer des triggers sur un 
      <quote>noeud déconnecté</quote> pour effectuer des traitements
      supplémentaires sur les données.</para>

  <para> Par exemple, vous pouvez prendre une base relativement <quote>statique</quote>
  et la transformer en une table <quote>temporelle</quote> , en utilisant
  des triggers qui that implémentent les techniques décrites dans
  <citation>Developing Time-Oriented Database Applications in SQL
  </citation> de <ulink url="http://www.cs.arizona.edu/people/rts/">
  Richard T. Snodgrass</ulink>.</para></listitem>

</itemizedlist></para>

<qandaset>
<qandaentry>

<question> <para> Où sont générés les <quote>fichiers de log</quote> d'un 
    ensemble de réplication donné ?</para>
</question>

<answer> <para> Chaque noeud abonné <link linkend="slon"> slon </link>
    peut les générer en ajoutant l'option <option>-a</option>.</para>

<note><para> Notez que cela implique que pour utiliser le log
shipping, vous devez avoir au moins un noeud abonné. </para></note>
</answer>

</qandaentry>

<qandaentry> <question> <para> Que se passe-t-il lors d'un  <xref
linkend="stmtfailover"/>/ <xref linkend="stmtmoveset"/> 
 se déclenche ?</para></question>

<answer><para> Rien de spécial. Tant que le noeud d'archivage rester un abonné
    il continue à produire des logs.</para></answer>

<answer> <warning> <para>Si le noeud d'archivage devient l'origine, il 
      continuera à produire des logs.</para> </warning></answer>
</qandaentry>

<qandaentry> <question> <para> Que se passe-t-il lorsqu'il n'y a plus assez d'espace 
      pour les fichiers de logs ?  </para></question>

<answer><para> Le noeud n'accepte plus les événements <command>SYNC</command>s
jusqu'à ce que le problÚme soit réglé. La base de donnée qui est dupliquée 
tombera également en panne. </para></answer>
</qandaentry>

<qandaentry>
<question> <para> Comment réaliser un abonnement ?  </para></question>

<answer><para> Le script dans <filename>tools</filename> nommé
<application>slony1_dump.sh</application> est un script shell qui 
exporte l'état <quote>actuel</quote> du noeud abonné.</para>

<para> Vous devez lancer le <application><link linkend="slon"> slon
</link></application> pour le noeud abonné avec log shipping activé.
À tout moment, vous pouvez lancer la commande 
<application>slony1_dump.sh</application>, qui va récupérer l'état 
de l'abonné sous la forme d'événements <command>SYNC</command>.
Une fois que l'export est complet, tous les logs <command>SYNC</command> 
produits à partir du moment où l'export a <emphasis>démarré</emphasis>
seront ajoutés à l'export afin d'obtenir un <quote>noeud abonné 
  au log shipping</quote>.
</para></answer>
</qandaentry>

<qandaentry> <question><para> Quelles sont les limitations du log
shipping ? </para>
</question>

<answer><para> Dans la version initiale, il y a beaucoup de limitations.
    Heureusement au fur et à mesure des nouvelles versions, certaines de ces 
    limitations ont été corrigées ou supprimées. </para> </answer>

<answer><para> La fonctionnalité du log shipping revient à 
<quote>sniffer</quote> les données appliquées sur un noeud abonné
. En conséquence, vous devez avoir au moins un noeud 
 <quote>standard</quote>; vous ne pouvez pas avoir un cluster composé
 seulement d'une origine et d'un ensemble de <quote>noeuds de log shipping
 </quote>. </para></answer>

<answer><para> Le <quote>noeud de log shipping</quote> traque
    la totalité du trafic allant vers un abonné. Vous pouvez
    séparer les choses lorsqu'il y a de multiple ensembles de 
    réplication. </para></answer>

<answer><para> Actuellement le <quote>noeud de log shipping </quote>
    traque uniquement les événements <command>SYNC</command>.
    Cela devrait être suffisant pour gérer <emphasis>certains</emphasis>
    changements de la configuration du cluster, mais pas tous.
 </para>

<para> Un bonne partie des types événements <emphasis> sont </emphasis> 
  gérés afin que le log shipping puissent les traités :

<itemizedlist>

<listitem><para>Bien évidemment, les événements <command>SYNC </command> sont gérés;
    </para></listitem>

<listitem><para>Les <command>DDL_SCRIPT</command> sont gérés.</para></listitem>

<listitem><para><command> UNSUBSCRIBE_SET </command></para> 

<para> Cet événement, tout comme <command>SUBSCRIBE_SET</command> n'est pas
  géré par le noeud de log shipping.  Mais cette commande, par définition,
  implique que les événements <command>SYNC</command> ne
  contiennent plus de mises à jour pour l'ensemble de réplication;
  </para>

<para> De la même façon, <command>SET_DROP_TABLE</command>,
<command>SET_DROP_SEQUENCE</command>,
<command>SET_MOVE_TABLE</command>,
<command>SET_MOVE_SEQUENCE</command> <command>DROP_SET</command>,
<command>MERGE_SET</command>, seront géré de maniÚre <quote>appropriée
</quote>;</para></listitem>

<listitem><para><command> SUBSCRIBE_SET </command></para>

<para> Malheureusement, des choses <quote>étranges</quote> lorsqu'on
  gÚre cette commande... Quand un <command>SUBSCRIBE_SET</command>
  se produit, cela déclenche un évÚnement nommé 
  <command>ENABLE_SUBSCRIPTION</command>
  qui est levé et traiter uniquement sur le noeud abonné;</para>

<para> <command> SUBSCRIBE_SET </command> est vraiment un événement
  trÚs simple, il se contente de <emphasis>déclarer</emphasis> 
  qu'un noeud s'abonne à un ensemble donné via un fournisseur donné.
   <emphasis>Il ne copie pas les données !</emphasis> </para>

<para> Le coeur du travail de souscription est réalisé par 
<command>ENABLE_SUBSCRIPTION</command>, qui est un événement
déclenché sur le noeud local, et non pas dans la même séquence
que les autres événements en provenance des autres noeuds ( notament
le fournisseur de données ). </para>

<para> Avec la modifications du traitement des logs intervenus dans la version 1.2.11,
ceci ne présente plus de problÚmes pour l'utilisateur.</para>

</listitem> 

<listitem><para> Les différents événements impliqués dans la configuration d'un 
    noeud sont inutiles dans le cadre du log shipping :

<command>STORE_NODE</command>,
<command>ENABLE_NODE</command>,
<command>DROP_NODE</command>,
<command>STORE_PATH</command>,
<command>DROP_PATH</command>,
<command>STORE_LISTEN</command>,
<command>DROP_LISTEN</command></para></listitem>

<listitem><para> Les événements impliqués dans la configuration
    des ensembles de réplication sont également inutiles :

<command>STORE_SET</command>,
<command>SET_ADD_TABLE</command>,
<command>SET_ADD_SEQUENCE</command>,
<command>STORE_TRIGGER</command>,
<command>DROP_TRIGGER</command>,
<command>TABLE_ADD_KEY</command>
</para></listitem>

</itemizedlist>
</para>
</answer>

<answer><para> Il serait pratique de transformer un noeud de  <quote>log
shipping</quote> est un noeud &slony1; complÚtement fonctionnel sur 
lequel on pourrait basculer. Cela serait utile  
(par exemple) pour un cluster de 6 noeuds; cela permettrait de 
commencer par créer noeud abonné puis d'utiliser le log shipping
pour construire les 4 autres noeuds en parallÚle.
</para>

<para> Cette utilisation n'est pas possible, mais on peut  ajouter
  la configuration &slony1; dans un noeud, et le promouvoir 
  en tant que nouveau noeud. 
  Encore une fois, c'est une simple question de programmation
  (mais ça n'est pas forcément si simple)... </para></answer>
</qandaentry>
</qandaset>

<sect2><title> Conseils d'utilisation </title>

<note> <para> Voici quelques notes plus ou moins structurées
    sur l'utilisation idéale du log shipping...</para> </note>

<itemizedlist>

<listitem><para> Vous ne  <emphasis>devez</emphasis> pas appliquer aveuglément
    les fichiers <command>SYNC</command> car on en peut pas prendre un
    fichier <command>SYNC</command> au hasard. 
    Si ce n'est pas un fichier approprié, alors la 
    commande <function> setsyncTracking_offline() </function> 
    échouera et votre session <application> psql</application>
    recevra la commande <command> ABORT</command>, puis recherchera 
    dans le fichier <command>SYNC</command> Ã  la recherche d'un 
    <command>COMMIT</command> ou d'un <command>ROLLBACK</command> afin 
    de continuer vers la prochaine transaction.</para>

<para> Mais nous <emphasis> savons </emphasis> que la totalité du 
  contenu du fichier va échouer ! Il est futile de continuer à analyser
  le reste du fichier.</para>

<para> Voici une meilleure idée : 

<itemizedlist>

<listitem><para> Tout d'abord, Lire les premiÚres lignes du fichier, jusqu'à 
    l'appel à la fonction <function> setsyncTracking_offline() </function>.
  </para></listitem>

<listitem><para> Essayez de l'appliquer jusque là .</para></listitem>

<listitem><para> Si cela échoue, alors il est futile de continuer;
lancez un <command>ROLLBACK</command> sur la transaction, et essayez
éventuellement un autre fichier.</para></listitem>

<listitem><para> Si l'appel à <function> setsyncTracking_offline()
</function> fonctionne, alors vous avez trouver le bon fichier de 
<command>SYNC</command> et vous pouvez l'appliquer.  Vous devrez 
probablement faire un <command>ROLLBACK</command> sur la transaction,
puis utiliser <application>psql</application> pour appliquer
la totalité des mises à jours contenues dans le fichier.
</para></listitem>

</itemizedlist></para>

<para> Afin de faciliter la récupération des premiÚres lignes
  des fichiers sync, le format a été conçu pour qu'une ligne
  de pointillée indique la fin de <quote>l'en-tête </quote> :

<programlisting>
-- Slony-I log shipping archive
-- Node 11, Event 656
start transaction;

select "_T1".setsyncTracking_offline(1, '655', '656', '2007-09-23 18:37:40.206342');
-- end of log archiving header
</programlisting></para></listitem>


<listitem><para> Notez que l'en-tête inclut le timestamp qui témoigne de la 
    date de l'événement SYNC. 
<programlisting>
-- Slony-I log shipping archive
-- Node 11, Event 109
start transaction;

select "_T1".setsyncTracking_offline(1, '96', '109', '2007-09-23 19:01:31.267403');
-- end of log archiving header
</programlisting></para>

<para> Ce timestamp représente la date où le <command>SYNC</command>
  a été déclenché sur le noeud d'origine.</para>

<para> La valeur est stockée dans la table de configuration 
sl_setsync_offline.</para>

<para> Si vous construisez une base dynamique, cela représente probablement
  le moment ou voudrez appliquer toute les données d'une tansaction de 
  de log shipping. </para>
</listitem>

<listitem><para> Vous pouvez trouver plus d'information sur 
    comment l'activité du noeud est enregistré dans 
    <xref linkend="logshiplog"/>. </para></listitem>

</itemizedlist>

<para> À partir de la version 1.2.11, il existe une méthode 
  <emphasis>encore meilleure</emphasis> pour appliquer les logs, car 
  leu rÚgle de nommage est devenu plus compréhensible.</para>

<itemizedlist>

<listitem><para> Les traces, sur le noeud de log shipping, qui
    indiquent quel est quel est le log le plus récemment 
    traité, sont stockées dans la table <envar>sl_archive_tracking</envar>. </para>

<para> Ainsi, vous pouvez prédire l'identifiant du prochain
  fichier de log en incrémentant le dernier identifiant de cette
  table.</para>
</listitem>

<listitem><para> Il existe néanmoins des variations dans le 
    nommage des fichiers, en fonction du nombre de noeuds
    qui composent le cluster. Tous les noeuds produisent 
    réguliÚrement des événements <command>SYNC</command>,
    même si ils ne sont pas le noeud origine, et le systÚme
    de log shipping génÚre des logs pour ces événements. </para>

<para> En conséquence, lorsque l'on cherche le fichier de log suivant,
  il est nécessaire de chercher de maniÚre suivante :

<programlisting>
ARCHIVEDIR=/var/spool/slony/archivelogs/node4
SLONYCLUSTER=mon_cluster
PGDATABASE=logshipdb
PGHOST=logshiphost
NEXTQUERY="select at_counter+1 from \"_${SLONYCLUSTER}\".sl_archive_tracking;"
nextseq=`psql -d ${PGDATABASE} -h ${PGHOST} -A -t -c "${NEXTQUERY}"
filespec=`printf "slony1_log_*_%20d.sql"
for file in `find $ARCHIVEDIR -name "${filespec}"; do
   psql -d ${PGDATABASE} -h ${PGHOST} -f ${file}
done
</programlisting>
</para>
</listitem>

<listitem><para> </para> </listitem>
</itemizedlist>

</sect2>

<sect2><title> <application> find-triggers-to-deactivate.sh
</application> </title>

<indexterm><primary> Désactivation des triggers </primary> </indexterm>

<para> Le <ulink
url="http://www.slony.info/bugzilla/show_bug.cgi?id=19"> bug
#19</ulink> indique que le dump d'un schéma peut contenir des
triggers et des rÚgles que l'on ne souhaite pas activer sur un 
noeud de log shipping.</para>

<para> L'outil <filename> tools/find-triggers-to-deactivate.sh
</filename> a été créé pour assister l'utilisateur dans cette tache.
Il peut être lancé sur un noeud qui sera utilisé comme schéma source,
et il liste les rÚgles et les triggers présents sur ce noeud qui devraient
être désactivés.</para>

<para> Cela comprend le triggers <function>logtrigger</function> 
  et <function>denyaccess</function> qui sont normalement exclut
  du schéma extrait avec pgdump. Il est toutefois de la responsabilité
  de l'administrateur de vérifier que des triggers comme ceux-ci
  sont bien retirés du réplicat du log shipping.
  </para>

</sect2>

<sect2> <title> L'outil <application>slony_logshipper </application></title>


<para> À partir de la version 1.2.12, &slony1; a un outil conçu pour
  aider à appliquer les logs, nommé <application>slony_logshipper</application>.
  Il fonctionne avec trois types de paramÚtres :
</para>

<itemizedlist>
<listitem><para> des options : </para> 
<itemizedlist>
<listitem><para><option>h</option> </para> <para>    affiche cette aide et se termine </para> </listitem>
<listitem><para><option>v</option> </para> <para>    affiche la version et se termine </para> </listitem>
<listitem><para><option>q</option> </para> <para>    mode silencieux </para> </listitem>
<listitem><para><option>l</option> </para> <para>    ordonne au démon de rouvrir le fichier </para> </listitem>
<listitem><para><option>r</option> </para> <para>    ordonne au démon de continuer aprÚs une erreur </para> </listitem>
<listitem><para><option>t</option> </para> <para>    ordonne au démon d'entrer en mode d'arrêt intelligent ("smart shutdown") </para> </listitem>
<listitem><para><option>T</option> </para> <para>    ordonne au démon d'entrer en mode d'arrêt immédiat </para> </listitem>
<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>
<listitem><para><option>f</option> </para> <para>    rester au premier plan (ne pas fonctionner en mode démon) </para> </listitem>
<listitem><para><option>w</option> </para> <para>    entrer immédiatement en mode d'arrêt intelligent</para> </listitem>
</itemizedlist>
</listitem>
<listitem><para> un fichier de configuration spécifique </para>
<para> Ce fichier est composé des paramÚtres suivants :</para>
<itemizedlist>
<listitem><para> <command>logfile = './offline_logs/logshipper.log';</command></para> 
<para> L'endroit où le log shipper laissera ses traces d'exécutions.</para> </listitem>
<listitem><para> <command>cluster name = 'T1';</command></para> <para> le nom du cluster </para> </listitem>
<listitem><para> <command>destination database  = 'dbname=slony_test3';</command></para> <para> Le paramÚtre conninfo 
    optionnel pour se connecter à la base destination. Si ce paramÚtre est fourni,
    le log shipper se connectera à cette base et y appliquera les logs. </para> </listitem>
<listitem><para> <command>archive dir = './offline_logs';</command></para> <para> Le répertoire d'archive 
    est obligatoire lorsqu'on est en mode <quote>connecté à une database</quote> afin de pouvoir
    scanner noeud à la recherche d'archives manquantes (ou non appliquées). </para> </listitem>
<listitem><para> <command>destination dir = './offline_result';</command></para> <para> Si ce paramÚtre est défini,
    le log shipper écrira les résultats du traitement des données à l'intérieur de fichiers
    de log placés dans ce répertoire.</para> </listitem>
<listitem><para> <command>max archives = 3600;</command></para> <para> Ce paramÚtre lutte
    contre d'éventuelles fuites mémoire; le démon entrera en mode d'arrêt intelligent( <quote>smart shutdown</quote> ) 
    automatiquement aprÚs avoir traiter ce nombre d'archives. </para> </listitem>
<listitem><para> <command>ignore table "public"."history";</command></para> <para> On peut exclure
    certaines tables du systÚme de log shipping</para> </listitem>
<listitem><para> <command>ignore namespace "public";</command></para> <para> On peut exclure
    un espace de noms du systÚme de réplication </para> </listitem>
<listitem><para> <command>rename namespace "public"."history" to "site_001"."history";</command></para> <para>
    On peut renommer des tables spécifiques.</para> </listitem>
<listitem><para> <command>rename namespace "public" to "site_001";</command></para> <para> 
    On peut renommer un espace de noms.</para> </listitem>
<listitem><para> <command>post processing command = 'gzip -9 $inarchive';</command></para> <para> 
    Les commandes de pré-traitement et post-traitement sont exécutées via la fonction <function>system(3)</function>. </para> </listitem>
</itemizedlist>
<para> Un <quote>@</quote> placé devant le nom de la commande permet d'ignorer un code de retour. Sinon, tout code
  de retour différent de zéro sera traité comme une erreur et provoquera l'arrêt du processus. </para>

<para> Par ailleurs les commandes de pré-traitement et de post-traitement ont accÚs à deux variables spéciales : </para>
<itemizedlist>
<listitem><para> <envar>$inarchive</envar>  - indique le nom du fichier d'archive en entrée </para> </listitem>
<listitem><para> <envar>$outnarchive</envar>  - indique le nom du fichier d'archive en sortie </para> </listitem>
</itemizedlist>
</listitem>

<listitem><para> <command>error command = ' ( echo
"archive=$inarchive" echo "error messages:" echo "$errortext" ) | mail
-s "Slony log shipping failed" postgres@localhost ';</command></para>

<para>  Le commande d'erreur indique quelle commande lancé lorsqu'une erreur est rencontrée.
  Toutes l'archivage réalisée depuis le dernier archive traité avec succÚs est disponible
  dans la variable <envar>$errortext</envar>. </para> 

<para> Dans l'exemple donné, un courriel est envoyé à l'administrateur
  lorsqu'une erreur est rencontrée.</para> </listitem>
</itemizedlist>

<itemizedlist>
<listitem><para> Noms des fichiers d'archive</para>

<para> Chaque nom de fichier est ajouté à la file d'attente des messages SystemV
  afin qu'un processus <application>slony_logshipper</application> le traite.</para>

</listitem>

</itemizedlist>

</sect2>
</sect1>