[Trad] [svn:pgfr] r1245 - in traduc/tags: . slony_1_2_12
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Lun 23 Fév 16:46:28 CET 2009
Author: gleu
Date: 2009-02-23 16:46:28 +0100 (Mon, 23 Feb 2009)
New Revision: 1245
Added:
traduc/tags/slony_1_2_12/
traduc/tags/slony_1_2_12/addthings.xml
traduc/tags/slony_1_2_12/adminscripts.xml
traduc/tags/slony_1_2_12/bestpractices.xml
traduc/tags/slony_1_2_12/defineset.xml
traduc/tags/slony_1_2_12/failover.xml
traduc/tags/slony_1_2_12/filelist.xml
traduc/tags/slony_1_2_12/firstdb.xml
traduc/tags/slony_1_2_12/installation.xml
traduc/tags/slony_1_2_12/legal.xml
traduc/tags/slony_1_2_12/loganalysis.xml
traduc/tags/slony_1_2_12/logshipping.xml
traduc/tags/slony_1_2_12/maintenance.xml
traduc/tags/slony_1_2_12/monitoring.xml
traduc/tags/slony_1_2_12/slon.xml
traduc/tags/slony_1_2_12/slonconf.xml
traduc/tags/slony_1_2_12/slonik_ref.xml
traduc/tags/slony_1_2_12/slony.xml
traduc/tags/slony_1_2_12/slonyupgrade.xml
traduc/tags/slony_1_2_12/subscribenodes.xml
traduc/tags/slony_1_2_12/supportedplatforms.xml
traduc/tags/slony_1_2_12/testbed.xml
traduc/tags/slony_1_2_12/usingslonik.xml
Removed:
traduc/tags/slony_1_2_12/addthings.xml
traduc/tags/slony_1_2_12/adminscripts.xml
traduc/tags/slony_1_2_12/bestpractices.xml
traduc/tags/slony_1_2_12/defineset.xml
traduc/tags/slony_1_2_12/failover.xml
traduc/tags/slony_1_2_12/filelist.xml
traduc/tags/slony_1_2_12/firstdb.xml
traduc/tags/slony_1_2_12/installation.xml
traduc/tags/slony_1_2_12/legal.xml
traduc/tags/slony_1_2_12/loganalysis.xml
traduc/tags/slony_1_2_12/logshipping.xml
traduc/tags/slony_1_2_12/maintenance.xml
traduc/tags/slony_1_2_12/monitoring.xml
traduc/tags/slony_1_2_12/slon.xml
traduc/tags/slony_1_2_12/slonconf.xml
traduc/tags/slony_1_2_12/slonik_ref.xml
traduc/tags/slony_1_2_12/slony.xml
traduc/tags/slony_1_2_12/slonyupgrade.xml
traduc/tags/slony_1_2_12/subscribenodes.xml
traduc/tags/slony_1_2_12/supportedplatforms.xml
traduc/tags/slony_1_2_12/testbed.xml
traduc/tags/slony_1_2_12/usingslonik.xml
Log:
Ajout du tag pour Slony 1.2.12.
Copied: traduc/tags/slony_1_2_12 (from rev 1243, traduc/trunk/slony)
Property changes on: traduc/tags/slony_1_2_12
___________________________________________________________________
Name: svn:mergeinfo
+
Deleted: traduc/tags/slony_1_2_12/addthings.xml
===================================================================
--- traduc/trunk/slony/addthings.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/addthings.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,608 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="addthings">
-<title>Ajouter des objets à la réplication</title>
-<indexterm><primary>ajouter des objets à la réplication</primary></indexterm>
-
-<para>
- Vous découvrirez peut-être que vous avez oubliez des choses que vous vouliez
- répliquer.
-</para>
-
-<para>
- En général, on peut très aisément y remédier. Cette section propose un
- <quote>tour d'horizon</quote> des moyens pour répondre à la question
- <quote>Comment réaliser la tache <emphasis>X</emphasis> avec
- &slony1; ?</quote>, pour différente valeur de <emphasis>X</emphasis>.
-</para>
-
-<para>
- On ne peut pas utiliser directement les commandes <xref
- linkend="stmtsetaddtable"/> ou <xref linkend="stmtsetaddsequence"/> de
- <xref linkend="slonik"/> pour ajouter des tables et des séquences à un
- ensemble de réplication en cours de fonctionnement ; on doit au
- contraire créer un nouvel ensemble de réplication. Une fois que ce nouvel
- ensemble est répliqué à l'identique (c'est-à-dire les fournisseurs et
- abonnés sont <emphasis>entièrement identiques</emphasis> à ceux de
- l'ensemble que l'on veut compléter), les deux ensembles peuvent être
- fusionnés avec la commande <xref linkend="stmtmergeset"/>.
- </para>
-
-<para>
- Jusqu'à la version 1.0.2 (incluse), il existait des risques potentiels si
- <xref linkend="stmtmergeset"/> était lancée alors que d'autres événements
- de type abonnement étaient en attente ; des confusions pouvaient se
- produire sur les nœuds ayant ces événements en attente. Ce problème
- fut résolu avec la version 1.0.5. Jusqu'à la version 1.2.1, il existait
- toujours un problème avec <xref linkend="stmtmergeset"/> si la commande
- était lancée avant que tous les abonnements soient complets, des
- <quote>perturbations</quote> pouvaient apparaître sur les nœuds où
- l'activité d'abonnement n'était pas terminée.
-</para>
-
-<para>
- Notez que si vous ajoutez des nœuds, vous devez également ajouter les
- déclarations <xref linkend="stmtstorepath"/> pour indiquer comment les
- nœuds communiquent entre eux, et les déclarations <xref
- linkend="stmtstorelisten"/> pour configurer le <quote>réseau de
- communications</quote> correspondant. Voir le chapitre <xref
- linkend="listenpaths"/> pour plus de détails.
-</para>
-
-<para>
- Il est conseillé d'être très prudent lorsqu'on ajoute des nœuds et des
- voies de communications. Par exemple, soumettre de multiples demandes
- d'abonnements à un ensemble donné dans un script <xref linkend="slonik"/>
- finit mal, en général. S'il est <emphasis>vraiment</emphasis> nécessaire
- d'automatiser cette étape, il est préférable de soumettre des requêtes
- <xref linkend="stmtwaitevent"/> entre chaque requête d'abonnement pour que
- le script <xref linkend="slonik"/> attende qu'un abonnement soit complet
- avant de lancer le suivant.
-</para>
-
-<para>
- Mais en général, il est plus facile de gérer les reconfigurations complexes
- en s'assurant qu'un changement a été parfaitement réussi avant de passer au
- suivant. Il est beaucoup plus simple de corriger un problème unique que de
- réparer les dégâts provoqués par l'interaction erronée de cinq commandes
- successives.
-</para>
-
-<para>
- Voici un ensemble de <quote>recettes</quote> pour réaliser différentes
- modifications sur la configuration de la réplication.
-</para>
-
-<sect2>
-<title>Ajouter une table dans le cluster de réplication</title>
-<indexterm><primary>ajouter une table dans le cluster de réplication</primary></indexterm>
-
-<para>
- &slony1; ne vous permet pas d'ajouter une table dans un ensemble qui est déjà
- en cours de réplication. En principe, c'est certainement
- <emphasis>possible</emphasis> ; mais cela implique que l'événement
- SET_ADD_TABLE produise le code adéquat à partir de l'événement SUBSCRIBE_SET
- invoqué pour analyser la table. Cela compliquerait de manière significative
- et regrettable la logique de tous ces composants, donc ce n'est pas permis.
-</para>
-
-<para>
- En contrepartie, vous devez procéder de la manière suivante :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>Ajouter la nouvelle table sur chaque nœud.</para>
-
- <para>
- En principe, le script <xref linkend="stmtddlscript"/> peut être utilisé
- pour cela, mais en réalité cela provoque des <link
- linkend="locking">problèmes d'inter-blocages</link> et cela nécessite la
- modification de <emphasis>toutes</emphasis> les tables dans l'ensemble de
- réplication existant, sur <emphasis>tous</emphasis> les nœuds, ce
- qui fait que <xref linkend="stmtddlscript"/> est une approche peu
- attrayante sur un serveur chargé. Ceci brise la règle de &slony1; qui dit
- qu'<quote>il n'est pas nécessaire d'interrompre l'activité normale pour
- ajouter la réplication</quote>.
- </para>
-
- <para>
- À contrario, vous pouvez ajouter la table via <application>psql</application>
- sur chaque nœud.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Créer un nouvel ensemble de réplication avec <xref linkend="stmtcreateset"/>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Ajouter la table dans le nouvel ensemble avec <xref
- linkend="stmtsetaddtable"/>
- </para>
- </listitem>
-
- <listitem>
- <para>
- Demander l'abonnement de ce nouvel ensemble avec <xref
- linkend="stmtsubscribeset"/>. S'il existe plusieurs nœuds, vous
- devez utiliser <xref linkend="stmtsubscribeset"/> une fois pour chaque
- nœud que vous voulez abonner.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si vous voulez savoir de manière déterministe si un abonnement est
- complet, vous devez soumettre pour chaque abonnement un script
- slonik qui ressemble à cela :
-
- <screen>SUBSCRIBE SET (ID=1, PROVIDER=1, RECEIVER=2);
-WAIT FOR EVENT (ORIGIN=2, CONFIRMED = 1);
-SYNC(ID = 1);
-WAIT FOR EVENT (ORIGIN=1, CONFIRMED=2);</screen>
- </para>
- </listitem>
-
- <listitem>
- <para>
- Une fois que les abonnements sont configurés de manière à ce que les
- abonnements du nouvel ensemble soient identiques à ceux de l'ancien
- ensemble, vous pouvez fusionner le nouveau et l'ancien avec la commande
- <xref linkend="stmtmergeset"/>.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-<sect2>
-<title>Comment ajouter une colonne dans une table répliquée</title>
-<indexterm><primary>ajouter des colonnes dans une table</primary></indexterm>
-
-<para>
- Cette réponse est la même que pour la question <quote>Comment renommer des
- colonnes dans une table répliquée ?</quote>, et plus généralement aux
- autres questions du type <quote>Comment modifier la définition de tables
- répliquées ?</quote>
-</para>
-
-<para>
- Si vous changez la <quote>forme</quote> d'une table répliquée, vous devez le
- faire au même instant dans le <quote>flux de transaction</quote> sur tous les
- nœuds qui sont abonnés à l'ensemble qui contient la table.
-</para>
-
-<para>
- Ainsi, la méthode consiste à construire un script SQL composé des changements
- DDL et de le soumettre à tous les nœuds via la commande Slonik <xref
- linkend="stmtddlscript"/>.
-</para>
-
-<para>
- Il existe une alternative si vous avec installé les <link
- linkend="altperl">scripts altperl</link>. Vous pouvez utiliser
- <command>slonik_execute_script</command> pour cela :
-</para>
-
-<para>
- <command>slonik_execute_script [options] numero_de_l_ensemble full_path_to_sql_script_file</command>
-</para>
-
-<para>
- Tapez la commande <command>slonik_execute_script -h</command> pour plus
- d'informations ; notez que ce script utilise <xref
- linkend="stmtddlscript"/>.
-</para>
-
-<para>
- Il y a de nombreux <quote>points délicats</quote> à noter...
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Vous <emphasis>ne devez absolument jamais</emphasis> inclure des
- commandes de contrôle de transaction, notamment <command>BEGIN</command>
- et <command>COMMIT</command>, à l'intérieur de ces scripts. &slony1;
- encapsule les scripts DDL avec une paire
- <command>BEGIN</command>/<command>COMMIT</command> ; ajouter des
- opérateurs de contrôle de transaction supplémentaires implique que des
- parties des ordres DDL seront <quote>validées</quote> en dehors du
- contrôle de &slony1;.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Avant la version 1.2, il était nécessaire d'être extrêmement restrictif
- sur ce qu'on envoyait au script <xref linkend="stmtddlscript"/>.
- </para>
-
- <para>
- Il était interdit de placer du texte <command>entre guillemets
- simples</command> dans le script car cela l'empêchait d'être stocké et
- transmis correctement. À partir de la version 1.2, les guillemets simples
- sont correctement prises en compte.
- </para>
-
- <para>
- Si vous soumettez une séries d'ordre DDL, les derniers ne peuvent pas
- faire référence aux objets créés par les premiers car tous les ordres
- sont soumis dans une requête unique, dont le plan d'exécution est basé
- sur l'état de la base de données au <emphasis>début</emphasis>, avant
- que les modifications ne soient effectuées. À partir de la version 1.2,
- il y a 12 ordres SQL, chacun est soumis individuellement ainsi la
- commande <command>ALTER TABLE x ADD COLUMN c1 integer;</command> peut
- désormais être suivie par <command>ALTER TABLE x ALTER COLUMN c1 SET NOT
- NULL;</command>.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-<sect2>
-<title>Comment supprimer la réplication sur un nœud</title>
-
-<para>
- Vous devez supprimer les différents composants &slony1; connectés à la base.
-</para>
-
-<para>
- Considérons, un instant, que nous faisons cela pour un nœud. Si vous
- avez de multiples nœuds, vous devrez répéter ces étapes autant de fois
- que nécessaire.
-</para>
-
-<para>
- Les composants à retirer :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>Triggers de logs / Triggers de blocage de mises à jour</para>
- </listitem>
-
- <listitem>
- <para>
- Le schéma <quote>cluster</quote> contenant les tables &slony1; indiquant
- l'état du nœud et diverses procédures stockées
- </para>
- </listitem>
-
- <listitem>
- <para>
- Le processus &lslon; qui gère le nœud
- </para>
- </listitem>
-
- <listitem>
- <para>
- Accessoirement, les scripts SQL, les scripts pl/pgsql et les binaires
- &slony1; qui font partie de la compilation de &postgres;. (Bien sûr,
- cela complique la tache si vous souhaitez redémarrer la réplication ;
- il est peu probable que vous ayez besoin de supprimer ces fichiers...)
- </para>
- </listitem>
-</itemizedlist>
-
-<para>Comment effectuer facilement la suppression</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Vous pouvez utiliser la commande Slonik <xref linkend="stmtdropnode"/>
- pour supprimer un nœud du cluster. Ceci provoquera la suppression
- des triggers et tout ce qui se trouve dans schéma cluster. Le processus
- <xref linkend="slon"/> va mourir automatiquement.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Dans le cas d'un nœud en échec (lorsque vous avez utilisé la
- commande <xref linkend="stmtfailover"/> pour basculer sur un autre
- nœud), vous devrez peut-être utiliser <xref
- linkend="stmtuninstallnode"/> pour supprimer les triggers, le schéma
- et les fonctions.
- </para>
-
- <para>
- Si le nœud est en échec à cause d'une panne matérielle dramatique
- (<emphasis>par exemple</emphasis> si vos disques ont pris feu), il est
- possible qu'il n'y ait plus de traces de la base de données sur le
- nœud ; en général, la base ne survit que lorsque la panne
- matérielle est un problème de réseau qui n'endommage pas les données
- mais qui vous oblige à supprimer le nœud à cause de coupures réseau
- persistantes.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si les opérations ci-dessus se sont particulièrement mal passée, vous
- pouvez lancer la commande SQL <command>DROP SCHEMA "Nom_du_cluster"
- CASCADE;</command> qui supprime toutes les fonctions, les tables et
- les triggers de &slony1;. En général, c'est une opération moins pratique
- que <xref linkend="stmtuninstallnode"/> car cette commande ne se contente
- pas de supprimer le schéma et son contenu, elle supprime également toutes
- les colonnes ajoutées avec la commande <xref linkend= "stmttableaddkey"/>.
- </para>
-
- <note>
- <para>
- Dans &slony1; version 2.0, <xref linkend="stmttableaddkey"/>
- <emphasis>n'est plus supporté</emphasis> et donc <xref
- linkend="stmtuninstallnode"/> correspond simplement à <command>DROP
- SCHEMA "nom_du_cluster" CASCADE;</command>.
- </para>
- </note>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-<sect2>
-<title>Ajouter un nœud dans le cluster de réplication</title>
-
-<para>
- Les choses ne sont pas fondamentalement différentes entre l'ajout d'un
- nœud flambant neuf et la restauration d'un nœud qu'on supprime
- puis reconstruit. Dans les deux cas, vous ajoutez un nœud dans le
- cluster de réplication.
-</para>
-
-<para>
- Les étapes nécessaires sont...
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Déterminer le numéro du nœud et les DSN adéquats pour le nœud.
- Utilisez la commande &postgres; <command>createdb</command> pour créer la
- base ; ajoutez les définitions des tables que vous voulez répliquer
- car &slony1; ne propage pas automatiquement cette information.
- </para>
-
- <para>
- Si vous ne disposez pas d'un script SQL parfaitement propre pour ajouter
- les tables, alors vous pouvez utiliser l'outil <link
- linkend="extractschema"><command>slony1_extract_schema.sh</command></link>
- situé dans le répertoire <filename>tools</filename> afin d'obtenir le
- schéma utilisateur sans les <quote>morceaux</quote> de &slony1;.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si le nœud était un nœud en échec, vous devez lancer la
- commande <xref linkend="stmtdropnode"/> de <xref linkend="slonik"/>
- afin de vous débarrasser de ses vestiges dans le cluster et de supprimer
- le schéma que &slony1; a créé.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Lancer la commande <xref linkend="stmtstorenode"/> de slonik pour établir
- le nouveau nœud.
- </para>
- </listitem>
-
- <listitem>
- <para>
- À cet instant, vous pouvez lancer le démon &lslon; sur le nouveau
- nœud. Il ne connaîtra rien des autres nœuds, donc les logs
- de ce nœud seront particulièrement calmes.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Lancer la commande slonik <xref linkend="stmtstorepath"/> pour indiquer
- comment les processus <xref linkend="slon"/> doivent communiquer avec le
- nouveau nœud. Dans la version 1.1 et suivante, cette commande
- génère automatiquement des lignes de la table des <link
- linkend="listenpaths">voies d'écoute</link>. Dans les versions
- précédentes, vous devez utiliser <xref linkend="stmtstorelisten"/> pour
- les générer manuellement.
- </para>
- </listitem>
-
- <listitem>
- <para>
- À cet instant, lancer le script <command>test_slony_state-dbi.pl</command>
- est une excellente idée. Ce script parcourt le cluster tout entier et
- pointe les anomalies qu'il trouve. Il peut notamment identifier une grande
- variété de problèmes de communication.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Lancer commande slonik <xref linkend="stmtsubscribeset"/> pour abonner le
- nœud à l'ensemble de réplication.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-<sect2>
-<title>Comment remanier les abonnements ?</title>
-
-<para>
- Par exemple, on souhaite que le nœud 3 reçoive les données en
- provenance du nœud 1, alors qu'actuellement il reçoit les données du
- nœud 2.
-</para>
-
-<para>
- Il ne s'agit pas d'un cas d'utilisation de la commande <xref
- linkend="stmtmoveset"/> car on ne souhaite pas déplacer l'origine, mais
- simplement remanier les abonnés.
-</para>
-
-<para>
- Pour cela, on peut simplement soumettre des requêtes <xref
- linkend="stmtsubscribeset"/> pour <emphasis>modifier</emphasis> les
- abonnements. Ces abonnements ne seront pas redémarrés à partir de zéro, mais
- simplement reconfigurés.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Comment utiliser le <link linkend="logshipping">Log Shipping</link> ?</title>
-
-<para>
- Cette question est largement débattue dans la section <link
- linkend="logshipping">Log Shipping</link>...
-</para>
-
-</sect2>
-
-<sect2>
-<title>Comment savoir si la réplication fonctionne ?</title>
-
-<para>
- La preuve ultime est le fait que les données ajoutées sur l'origine soient
- présentes sur les abonnés. Il suffit <quote>simplement de lancer une
- requête</quote> pour le savoir.
-</para>
-
-<para>
- Cependant, il existe quelques autres méthode pour examiner l'état de la
- réplication :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>Regarder les logs des processus &lslon;.</para>
-
- <para>
- Ils ne vous diront pas grand chose, même à un niveau de débogage
- élevé sur le nœud origine. Au niveau 2 de débogage, vous devriez
- voir sur les abonnés les événements SYNCs qui sont en cours de
- traitement. À partir de la version 1.2, les informations sur le
- traitement des SYNC incluent le nombre de tables traitées, ainsi que
- le nombre de lignes insérées, supprimées et mises à jour.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Regarder dans la vue <command> sl_status </command> sur le nœud
- origine.
- </para>
-
- <para>
- Cette vue indique quel est le retard des différents nœuds abonnés.
- Cette information n'est pertinente que sur un nœud origine.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Lancer le script <command>test_slony_state-dbi.pl</command> qui se trouve
- dans le répertoire <filename>tools</filename>. Ce script parcourt le cluster
- tout entier et pointe les anomalies qu'il détecte, ainsi que des
- informations sur le statut de chaque nœud.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-<sect2>
-<title>Comment mettre à jour la version de &slony1; ?</title>
-
-<para>
- La réponse se trouve <link linkend="slonyupgrade">ici</link>.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Que se passe-t-il lors d'une bascule d'urgence ?</title>
-
-<para>
- Une partie de la réponse se trouve dans la section <xref linkend="failover"/>
- mais il reste beaucoup de choses à écrire sur le sujet...
-</para>
-
-</sect2>
-
-<sect2>
-<title>Comment <quote>déplacer le maître</quote> vers un autre nœud ?</title>
-
-<para>
- Tout d'abord il faut choisir un nœud qui est connecté à l'ancienne origine
- (sinon il n'est pas évident de conserver les connexions lors du changement).
-</para>
-
-<para>
- Deuxièmement, vous devez lancer un script &lslonik; avec la commande <xref
- linkend="stmtlockset"/> pour verrouiller l'ensemble de réplication sur le
- nœud origine. Notez qu'à cet instant votre application risque de ne
- plus fonctionner car cette opération pose des triggers sur l'origine qui
- rejetent toutes les mises à jour.
-</para>
-
-<para>
- Maintenant, lancez la requête &lslonik; <xref linkend="stmtmoveset"/>. Il est
- parfaitement raisonnable de soumettre les deux requêtes à l'intérieur d'un
- même script &lslonik;. Désormais, l'origine est basculée vers le nouveau
- nœud origine. Si le nouveau nœud a quelques événement de retard,
- il faudra un peu de temps pour que tout se mette en place.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Comment réaliser une <quote>synchronisation complète</quote> sur une table ?</title>
-
-<para>
- Pour &slony1;, la notion de <command>SYNC</command> est toujours quelque
- chose d'<emphasis>incrémental</emphasis> ; un <command>SYNC</command>
- représente un ensemble de mises à jour qui furent <quote>validées</quote>
- pendant la durée d'un événement <command>SYNC</command> donné sur le
- nœud origine. Si des mises à jour qui ont altéré l'ensemble du contenu
- d'une table sont <quote>validées</quote> au cours d'un <command>SYNC</command>
- unique, alors cela affectera l'ensemble du contenu de la table. Mais du point
- de vue de &slony1;, ce changement est <quote>incrémental</quote> même si la
- modification concerne <quote>la table toute entière</quote>.
-</para>
-
-<para>
- La seule fois où &slony1; <quote>synchronise</quote> le contenu d'une table
- est lors de la mise en place de l'abonnement. À ce moment-là, il utilise la
- commande <command>COPY</command> pour rapatrier la totalité du contenu de la
- table à partir du nœud fournisseur.
-</para>
-
-<para>
- Puisque les tables abonnées sont protégées contre les modifications réalisées
- par un autre utilisateur que &slony1;, il est impossible (mis à part
- d'horribles bogues) que les tables soient désynchronisées. Si c'est le cas,
- alors il y a vraiment un gros problème dans &slony1;.
-</para>
-
-<para>
- Si une corruption très grave se produit, la solution est de retirer la table
- de la réplication, puis de créer un nouvel ensemble de réplication et de
- l'ajouter à nouveau.
-</para>
-
-</sect2>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/addthings.xml (from rev 1244, traduc/trunk/slony/addthings.xml)
===================================================================
--- traduc/tags/slony_1_2_12/addthings.xml (rev 0)
+++ traduc/tags/slony_1_2_12/addthings.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,599 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="addthings">
+<title>Ajouter des objets à la réplication</title>
+<indexterm><primary>ajouter des objets à la réplication</primary></indexterm>
+
+<para>
+ Vous découvrirez peut-être que vous avez oubliez des choses que vous vouliez
+ répliquer.
+</para>
+
+<para>
+ En général, on peut très aisément y remédier. Cette section propose un
+ <quote>tour d'horizon</quote> des moyens pour répondre à la question
+ <quote>Comment réaliser la tache <emphasis>X</emphasis> avec
+ &slony1; ?</quote>, pour différente valeur de <emphasis>X</emphasis>.
+</para>
+
+<para>
+ On ne peut pas utiliser directement les commandes <xref
+ linkend="stmtsetaddtable"/> ou <xref linkend="stmtsetaddsequence"/> de
+ <xref linkend="slonik"/> pour ajouter des tables et des séquences à un
+ ensemble de réplication en cours de fonctionnement ; on doit au
+ contraire créer un nouvel ensemble de réplication. Une fois que ce nouvel
+ ensemble est répliqué à l'identique (c'est-à-dire les fournisseurs et
+ abonnés sont <emphasis>entièrement identiques</emphasis> à ceux de
+ l'ensemble que l'on veut compléter), les deux ensembles peuvent être
+ fusionnés avec la commande <xref linkend="stmtmergeset"/>.
+ </para>
+
+<para>
+ Jusqu'à la version 1.0.2 (incluse), il existait des risques potentiels si
+ <xref linkend="stmtmergeset"/> était lancée alors que d'autres événements
+ de type abonnement étaient en attente ; des confusions pouvaient se
+ produire sur les nœuds ayant ces événements en attente. Ce problème
+ fut résolu avec la version 1.0.5. Jusqu'à la version 1.2.1, il existait
+ toujours un problème avec <xref linkend="stmtmergeset"/> si la commande
+ était lancée avant que tous les abonnements soient complets, des
+ <quote>perturbations</quote> pouvaient apparaître sur les nœuds où
+ l'activité d'abonnement n'était pas terminée.
+</para>
+
+<para>
+ Notez que si vous ajoutez des nœuds, vous devez également ajouter les
+ déclarations <xref linkend="stmtstorepath"/> pour indiquer comment les
+ nœuds communiquent entre eux, et les déclarations <xref
+ linkend="stmtstorelisten"/> pour configurer le <quote>réseau de
+ communications</quote> correspondant. Voir le chapitre <xref
+ linkend="listenpaths"/> pour plus de détails.
+</para>
+
+<para>
+ Il est conseillé d'être très prudent lorsqu'on ajoute des nœuds et des
+ voies de communications. Par exemple, soumettre de multiples demandes
+ d'abonnements à un ensemble donné dans un script <xref linkend="slonik"/>
+ finit mal, en général. S'il est <emphasis>vraiment</emphasis> nécessaire
+ d'automatiser cette étape, il est préférable de soumettre des requêtes
+ <xref linkend="stmtwaitevent"/> entre chaque requête d'abonnement pour que
+ le script <xref linkend="slonik"/> attende qu'un abonnement soit complet
+ avant de lancer le suivant.
+</para>
+
+<para>
+ Mais en général, il est plus facile de gérer les reconfigurations complexes
+ en s'assurant qu'un changement a été parfaitement réussi avant de passer au
+ suivant. Il est beaucoup plus simple de corriger un problème unique que de
+ réparer les dégâts provoqués par l'interaction erronée de cinq commandes
+ successives.
+</para>
+
+<para>
+ Voici un ensemble de <quote>recettes</quote> pour réaliser différentes
+ modifications sur la configuration de la réplication.
+</para>
+
+<sect2>
+<title>Ajouter une table dans le cluster de réplication</title>
+<indexterm><primary>ajouter une table dans le cluster de réplication</primary></indexterm>
+
+<para>
+ &slony1; ne vous permet pas d'ajouter une table dans un ensemble qui est déjà
+ en cours de réplication. En principe, c'est certainement
+ <emphasis>possible</emphasis> ; mais cela implique que l'événement
+ SET_ADD_TABLE produise le code adéquat à partir de l'événement SUBSCRIBE_SET
+ invoqué pour analyser la table. Cela compliquerait de manière significative
+ et regrettable la logique de tous ces composants, donc ce n'est pas permis.
+</para>
+
+<para>
+ En contrepartie, vous devez procéder de la manière suivante :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>Ajouter la nouvelle table sur chaque nœud.</para>
+
+ <para>
+ En principe, le script <xref linkend="stmtddlscript"/> peut être utilisé
+ pour cela, mais en réalité cela provoque des <link
+ linkend="locking">problèmes d'inter-blocages</link> et cela nécessite la
+ modification de <emphasis>toutes</emphasis> les tables dans l'ensemble de
+ réplication existant, sur <emphasis>tous</emphasis> les nœuds, ce
+ qui fait que <xref linkend="stmtddlscript"/> est une approche peu
+ attrayante sur un serveur chargé. Ceci brise la règle de &slony1; qui dit
+ qu'<quote>il n'est pas nécessaire d'interrompre l'activité normale pour
+ ajouter la réplication</quote>.
+ </para>
+
+ <para>
+ À contrario, vous pouvez ajouter la table via <application>psql</application>
+ sur chaque nœud.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Créer un nouvel ensemble de réplication avec <xref linkend="stmtcreateset"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Ajouter la table dans le nouvel ensemble avec <xref
+ linkend="stmtsetaddtable"/>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Demander l'abonnement de ce nouvel ensemble avec <xref
+ linkend="stmtsubscribeset"/>. S'il existe plusieurs nœuds, vous
+ devez utiliser <xref linkend="stmtsubscribeset"/> une fois pour chaque
+ nœud que vous voulez abonner.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si vous voulez savoir de manière déterministe si un abonnement est
+ complet, vous devez soumettre pour chaque abonnement un script
+ slonik qui ressemble à cela :
+
+ <screen>SUBSCRIBE SET (ID=1, PROVIDER=1, RECEIVER=2);
+WAIT FOR EVENT (ORIGIN=2, CONFIRMED = 1);
+SYNC(ID = 1);
+WAIT FOR EVENT (ORIGIN=1, CONFIRMED=2);</screen>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Une fois que les abonnements sont configurés de manière à ce que les
+ abonnements du nouvel ensemble soient identiques à ceux de l'ancien
+ ensemble, vous pouvez fusionner le nouveau et l'ancien avec la commande
+ <xref linkend="stmtmergeset"/>.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2>
+<title>Comment ajouter une colonne dans une table répliquée</title>
+<indexterm><primary>ajouter des colonnes dans une table</primary></indexterm>
+
+<para>
+ Cette réponse est la même que pour la question <quote>Comment renommer des
+ colonnes dans une table répliquée ?</quote>, et plus généralement aux
+ autres questions du type <quote>Comment modifier la définition de tables
+ répliquées ?</quote>
+</para>
+
+<para>
+ Si vous changez la <quote>forme</quote> d'une table répliquée, vous devez le
+ faire au même instant dans le <quote>flux de transaction</quote> sur tous les
+ nœuds qui sont abonnés à l'ensemble qui contient la table.
+</para>
+
+<para>
+ Ainsi, la méthode consiste à construire un script SQL composé des changements
+ DDL et de le soumettre à tous les nœuds via la commande Slonik <xref
+ linkend="stmtddlscript"/>.
+</para>
+
+<para>
+ Il existe une alternative si vous avec installé les <link
+ linkend="altperl">scripts altperl</link>. Vous pouvez utiliser
+ <command>slonik_execute_script</command> pour cela :
+</para>
+
+<para>
+ <command>slonik_execute_script [options] numero_de_l_ensemble full_path_to_sql_script_file</command>
+</para>
+
+<para>
+ Tapez la commande <command>slonik_execute_script -h</command> pour plus
+ d'informations ; notez que ce script utilise <xref
+ linkend="stmtddlscript"/>.
+</para>
+
+<para>
+ Il y a de nombreux <quote>points délicats</quote> à noter...
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Vous <emphasis>ne devez absolument jamais</emphasis> inclure des
+ commandes de contrôle de transaction, notamment <command>BEGIN</command>
+ et <command>COMMIT</command>, à l'intérieur de ces scripts. &slony1;
+ encapsule les scripts DDL avec une paire
+ <command>BEGIN</command>/<command>COMMIT</command> ; ajouter des
+ opérateurs de contrôle de transaction supplémentaires implique que des
+ parties des ordres DDL seront <quote>validées</quote> en dehors du
+ contrôle de &slony1;.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Avant la version 1.2, il était nécessaire d'être extrêmement restrictif
+ sur ce qu'on envoyait au script <xref linkend="stmtddlscript"/>.
+ </para>
+
+ <para>
+ Il était interdit de placer du texte <command>entre guillemets
+ simples</command> dans le script car cela l'empêchait d'être stocké et
+ transmis correctement. À partir de la version 1.2, les guillemets simples
+ sont correctement prises en compte.
+ </para>
+
+ <para>
+ Si vous soumettez une séries d'ordre DDL, les derniers ne peuvent pas
+ faire référence aux objets créés par les premiers car tous les ordres
+ sont soumis dans une requête unique, dont le plan d'exécution est basé
+ sur l'état de la base de données au <emphasis>début</emphasis>, avant
+ que les modifications ne soient effectuées. À partir de la version 1.2,
+ il y a 12 ordres SQL, chacun est soumis individuellement ainsi la
+ commande <command>ALTER TABLE x ADD COLUMN c1 integer;</command> peut
+ désormais être suivie par <command>ALTER TABLE x ALTER COLUMN c1 SET NOT
+ NULL;</command>.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2>
+<title>Comment supprimer la réplication sur un nœud</title>
+
+<para>
+ Vous devez supprimer les différents composants &slony1; connectés à la base.
+</para>
+
+<para>
+ Considérons, un instant, que nous faisons cela pour un nœud. Si vous
+ avez de multiples nœuds, vous devrez répéter ces étapes autant de fois
+ que nécessaire.
+</para>
+
+<para>
+ Les composants à retirer :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>Triggers de logs / Triggers de blocage de mises à jour</para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Le schéma <quote>cluster</quote> contenant les tables &slony1; indiquant
+ l'état du nœud et diverses procédures stockées
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Le processus &lslon; qui gère le nœud
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Accessoirement, les scripts SQL, les scripts pl/pgsql et les binaires
+ &slony1; qui font partie de la compilation de &postgres;. (Bien sûr,
+ cela complique la tache si vous souhaitez redémarrer la réplication ;
+ il est peu probable que vous ayez besoin de supprimer ces fichiers...)
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>Comment effectuer facilement la suppression</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Vous pouvez utiliser la commande Slonik <xref linkend="stmtdropnode"/>
+ pour supprimer un nœud du cluster. Ceci provoquera la suppression
+ des triggers et tout ce qui se trouve dans schéma cluster. Le processus
+ <xref linkend="slon"/> va mourir automatiquement.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Dans le cas d'un nœud en échec (lorsque vous avez utilisé la
+ commande <xref linkend="stmtfailover"/> pour basculer sur un autre
+ nœud), vous devrez peut-être utiliser <xref
+ linkend="stmtuninstallnode"/> pour supprimer les triggers, le schéma
+ et les fonctions.
+ </para>
+
+ <para>
+ Si le nœud est en échec à cause d'une panne matérielle dramatique
+ (<emphasis>par exemple</emphasis> si vos disques ont pris feu), il est
+ possible qu'il n'y ait plus de traces de la base de données sur le
+ nœud ; en général, la base ne survit que lorsque la panne
+ matérielle est un problème de réseau qui n'endommage pas les données
+ mais qui vous oblige à supprimer le nœud à cause de coupures réseau
+ persistantes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si les opérations ci-dessus se sont particulièrement mal passée, vous
+ pouvez lancer la commande SQL <command>DROP SCHEMA "Nom_du_cluster"
+ CASCADE;</command> qui supprime toutes les fonctions, les tables et
+ les triggers de &slony1;. En général, c'est une opération moins pratique
+ que <xref linkend="stmtuninstallnode"/> car cette commande ne se contente
+ pas de supprimer le schéma et son contenu, elle supprime également toutes
+ les colonnes ajoutées avec la commande <xref linkend= "stmttableaddkey"/>.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2>
+<title>Ajouter un nœud dans le cluster de réplication</title>
+
+<para>
+ Les choses ne sont pas fondamentalement différentes entre l'ajout d'un
+ nœud flambant neuf et la restauration d'un nœud qu'on supprime
+ puis reconstruit. Dans les deux cas, vous ajoutez un nœud dans le
+ cluster de réplication.
+</para>
+
+<para>
+ Les étapes nécessaires sont...
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Déterminer le numéro du nœud et les DSN adéquats pour le nœud.
+ Utilisez la commande &postgres; <command>createdb</command> pour créer la
+ base ; ajoutez les définitions des tables que vous voulez répliquer
+ car &slony1; ne propage pas automatiquement cette information.
+ </para>
+
+ <para>
+ Si vous ne disposez pas d'un script SQL parfaitement propre pour ajouter
+ les tables, alors vous pouvez utiliser l'outil <link
+ linkend="extractschema"><command>slony1_extract_schema.sh</command></link>
+ situé dans le répertoire <filename>tools</filename> afin d'obtenir le
+ schéma utilisateur sans les <quote>morceaux</quote> de &slony1;.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si le nœud était un nœud en échec, vous devez lancer la
+ commande <xref linkend="stmtdropnode"/> de <xref linkend="slonik"/>
+ afin de vous débarrasser de ses vestiges dans le cluster et de supprimer
+ le schéma que &slony1; a créé.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Lancer la commande <xref linkend="stmtstorenode"/> de slonik pour établir
+ le nouveau nœud.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ À cet instant, vous pouvez lancer le démon &lslon; sur le nouveau
+ nœud. Il ne connaîtra rien des autres nœuds, donc les logs
+ de ce nœud seront particulièrement calmes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Lancer la commande slonik <xref linkend="stmtstorepath"/> pour indiquer
+ comment les processus <xref linkend="slon"/> doivent communiquer avec le
+ nouveau nœud. Dans la version 1.1 et suivante, cette commande
+ génère automatiquement des lignes de la table des <link
+ linkend="listenpaths">voies d'écoute</link>. Dans les versions
+ précédentes, vous devez utiliser <xref linkend="stmtstorelisten"/> pour
+ les générer manuellement.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ À cet instant, lancer le script <command>test_slony_state-dbi.pl</command>
+ est une excellente idée. Ce script parcourt le cluster tout entier et
+ pointe les anomalies qu'il trouve. Il peut notamment identifier une grande
+ variété de problèmes de communication.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Lancer commande slonik <xref linkend="stmtsubscribeset"/> pour abonner le
+ nœud à l'ensemble de réplication.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2>
+<title>Comment remanier les abonnements ?</title>
+
+<para>
+ Par exemple, on souhaite que le nœud 3 reçoive les données en
+ provenance du nœud 1, alors qu'actuellement il reçoit les données du
+ nœud 2.
+</para>
+
+<para>
+ Il ne s'agit pas d'un cas d'utilisation de la commande <xref
+ linkend="stmtmoveset"/> car on ne souhaite pas déplacer l'origine, mais
+ simplement remanier les abonnés.
+</para>
+
+<para>
+ Pour cela, on peut simplement soumettre des requêtes <xref
+ linkend="stmtsubscribeset"/> pour <emphasis>modifier</emphasis> les
+ abonnements. Ces abonnements ne seront pas redémarrés à partir de zéro, mais
+ simplement reconfigurés.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Comment utiliser le <link linkend="logshipping">Log Shipping</link> ?</title>
+
+<para>
+ Cette question est largement débattue dans la section <link
+ linkend="logshipping">Log Shipping</link>...
+</para>
+
+</sect2>
+
+<sect2>
+<title>Comment savoir si la réplication fonctionne ?</title>
+
+<para>
+ La preuve ultime est le fait que les données ajoutées sur l'origine soient
+ présentes sur les abonnés. Il suffit <quote>simplement de lancer une
+ requête</quote> pour le savoir.
+</para>
+
+<para>
+ Cependant, il existe quelques autres méthode pour examiner l'état de la
+ réplication :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>Regarder les logs des processus &lslon;.</para>
+
+ <para>
+ Ils ne vous diront pas grand chose, même à un niveau de débogage
+ élevé sur le nœud origine. Au niveau 2 de débogage, vous devriez
+ voir sur les abonnés les événements SYNCs qui sont en cours de
+ traitement. À partir de la version 1.2, les informations sur le
+ traitement des SYNC incluent le nombre de tables traitées, ainsi que
+ le nombre de lignes insérées, supprimées et mises à jour.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Regarder dans la vue <command> sl_status </command> sur le nœud
+ origine.
+ </para>
+
+ <para>
+ Cette vue indique quel est le retard des différents nœuds abonnés.
+ Cette information n'est pertinente que sur un nœud origine.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Lancer le script <command>test_slony_state-dbi.pl</command> qui se trouve
+ dans le répertoire <filename>tools</filename>. Ce script parcourt le cluster
+ tout entier et pointe les anomalies qu'il détecte, ainsi que des
+ informations sur le statut de chaque nœud.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2>
+<title>Comment mettre à jour la version de &slony1; ?</title>
+
+<para>
+ La réponse se trouve <link linkend="slonyupgrade">ici</link>.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Que se passe-t-il lors d'une bascule d'urgence ?</title>
+
+<para>
+ Une partie de la réponse se trouve dans la section <xref linkend="failover"/>
+ mais il reste beaucoup de choses à écrire sur le sujet...
+</para>
+
+</sect2>
+
+<sect2>
+<title>Comment <quote>déplacer le maître</quote> vers un autre nœud ?</title>
+
+<para>
+ Tout d'abord il faut choisir un nœud qui est connecté à l'ancienne origine
+ (sinon il n'est pas évident de conserver les connexions lors du changement).
+</para>
+
+<para>
+ Deuxièmement, vous devez lancer un script &lslonik; avec la commande <xref
+ linkend="stmtlockset"/> pour verrouiller l'ensemble de réplication sur le
+ nœud origine. Notez qu'à cet instant votre application risque de ne
+ plus fonctionner car cette opération pose des triggers sur l'origine qui
+ rejetent toutes les mises à jour.
+</para>
+
+<para>
+ Maintenant, lancez la requête &lslonik; <xref linkend="stmtmoveset"/>. Il est
+ parfaitement raisonnable de soumettre les deux requêtes à l'intérieur d'un
+ même script &lslonik;. Désormais, l'origine est basculée vers le nouveau
+ nœud origine. Si le nouveau nœud a quelques événement de retard,
+ il faudra un peu de temps pour que tout se mette en place.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Comment réaliser une <quote>synchronisation complète</quote> sur une table ?</title>
+
+<para>
+ Pour &slony1;, la notion de <command>SYNC</command> est toujours quelque
+ chose d'<emphasis>incrémental</emphasis> ; un <command>SYNC</command>
+ représente un ensemble de mises à jour qui furent <quote>validées</quote>
+ pendant la durée d'un événement <command>SYNC</command> donné sur le
+ nœud origine. Si des mises à jour qui ont altéré l'ensemble du contenu
+ d'une table sont <quote>validées</quote> au cours d'un <command>SYNC</command>
+ unique, alors cela affectera l'ensemble du contenu de la table. Mais du point
+ de vue de &slony1;, ce changement est <quote>incrémental</quote> même si la
+ modification concerne <quote>la table toute entière</quote>.
+</para>
+
+<para>
+ La seule fois où &slony1; <quote>synchronise</quote> le contenu d'une table
+ est lors de la mise en place de l'abonnement. À ce moment-là, il utilise la
+ commande <command>COPY</command> pour rapatrier la totalité du contenu de la
+ table à partir du nœud fournisseur.
+</para>
+
+<para>
+ Puisque les tables abonnées sont protégées contre les modifications réalisées
+ par un autre utilisateur que &slony1;, il est impossible (mis à part
+ d'horribles bogues) que les tables soient désynchronisées. Si c'est le cas,
+ alors il y a vraiment un gros problème dans &slony1;.
+</para>
+
+<para>
+ Si une corruption très grave se produit, la solution est de retirer la table
+ de la réplication, puis de créer un nouvel ensemble de réplication et de
+ l'ajouter à nouveau.
+</para>
+
+</sect2>
+
+</sect1>
Deleted: traduc/tags/slony_1_2_12/adminscripts.xml
===================================================================
--- traduc/trunk/slony/adminscripts.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/adminscripts.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,1194 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="adminscripts">
-<title>Scripts d'administration</title>
-<indexterm><primary>scripts d'administration de &slony1;</primary></indexterm>
-
-<para>
- Un certain nombre de scripts ont été développés tout au long de l'histoire de
- &slony1; pour aider les utilisateurs à gérer leurs clusters. Cette section
- ainsi que celle sur le <xref linkend="monitoring"/> et la <xref
- linkend="maintenance"/> décrit leur utilisation.
-</para>
-
-<sect2 id="altperl">
-<title>Les scripts altperl</title>
-<indexterm><primary>Script altperl pour &slony1;</primary></indexterm>
-
-<para>
- Il existe un ensemble de scripts qui simplifie l'administration de plusieurs
- instances &slony1;. Ces scripts supportent une nombre variable de nœuds.
- Ils peuvent être installés pendant le processus d'installation :
-</para>
-
-<para>
- <command>./configure --with-perltools</command>
-</para>
-
-<para>
- Ceci va produire un certain nombre de scripts avec le préfixe
- <command>slonik_</command>. Ils éliminent les risques de confusion en se
- référençant à un fichier central de configuration qui contient les détails
- de la configuration de votre site. Un exemple documenté de ce fichier est
- fourni dans <filename>altperl/slon_tools.conf-sample</filename>. La plupart
- dispose également d'une aide en ligne grâce à l'option "--help", ce qui les
- rend plus facile à prendre en main et à utiliser.
-</para>
-
-<para>
- La plupart des scripts de génération Slonik utilise la sortie STDOUT. Pendant
- un temps, les commandes étaient passées directement à <xref linkend="slonik"/>
- pour qu'il les exécute. Malheureusement, il s'agit d'une méthode trop
- <quote>agressive</quote> car de légères coquilles dans la ligne de commande
- peuvent conduire, dans certains cas, à des situations calamiteuses. Tout
- administrateur qui se respecte doit relire le script
- <emphasis>avant</emphasis> de l'envoyer à <xref linkend="slonik"/>.
-</para>
-
-<sect3>
-<title>Gestion de multiples clusters</title>
-<indexterm><primary>gérer de multiples clusters avec les outils altperl</primary></indexterm>
-
-<para>
- La variable d'environnement <envar>SLONYNODES</envar> est utilisée pour
- déterminer le fichier de configuration Perl qui sera utilisé pour contrôler
- les nœuds du cluster &slony1;. Si elle n'est pas fournie, le fichier
- <filename>slon_tools.conf</filename> situé dans l'emplacement par défaut
- sera utilisé.
-</para>
-
-<para>
- Voici la liste des variables qui peuvent être configurées :
- <itemizedlist>
- <listitem>
- <para>
- <envar>$CLUSTER_NAME</envar>=orglogs; # Quel est le nom du cluster de
- réplication ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>$LOGDIR</envar>='/opt/OXRS/log/LOGDBS'; # Quel est le répertoire
- des logs ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>$APACHE_ROTATOR</envar>="/opt/twcsds004/OXRS/apache/rotatelogs";
- # Si ce paramètre est défini, il indique où trouver le gestionnaire de
- gestion des traces d'Apache
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>foldCase</envar> # Si la valeur est 1, les noms d'objet (y
- compris les noms de schéma) sont transformés en minuscule. Par
- défaut, les noms d'objets restent inchangés. Notons que &postgres;
- lui-même transforme les noms d'objets en minuscule. Si vous créez
- une table avec la commande <command>CREATE TABLE MA_TABLE (Id INTEGER,
- MoNChamp text);</command>, le résultat sera équivalent à
- <command>create table ma_table (id integer, monchamp text);</command>,
- le nom de la table et celui de ses champs seront transformés en
- minuscule.
- </para>
- </listitem>
- </itemizedlist>
-</para>
-
-<para>
- Vous pouvez ensuite définir un ensemble de nœuds qui participeront à
- la réplication en utilisant plusieurs appels à la fonction
- <function>add_node()</function>.
-</para>
-
-<para>
- <command>add_node (host => '10.20.30.40', dbname => 'orglogs',
- port => 5437, user => 'postgres', node => 4, parent => 1);</command>
-</para>
-
-<para>
- Les paramètres de la fonction <function>add_node()</function> sont les
- suivants :
-</para>
-
-<programlisting>my %PARAMS = (host=> undef, # nom de l'hôte
- dbname => 'template1', # nom de la base
- port => 5432, # numéro du port
- user => 'postgres', # utilisateur de la connexion
- node => undef, # numéro du nœud
- password => undef, # mot de passe de l'utilisateur
- parent => 1, # l'identifiant du nœud père
- noforward => undef # ce nœud doit-il retransmettre les modifications ?
- sslmode => undef # mode SSL - détermine la priorité
- # d'utilisation de la couche SSL
- # = disable,allow,prefer,require
-);</programlisting>
-
-</sect3>
-
-<sect3>
-<title>Configuration d'un ensemble de réplication</title>
-<indexterm><primary>cluster.set1 - configuration d'un ensemble de réplication
-pour les outils Perl</primary></indexterm>
-
-<para>
- La variable d'environnement UNIX <envar>SLONYSET</envar> est utilisée pour
- déterminer le fichier de configuration à lire pour connaître les objets qui
- sont contenus dans un ensemble donné.
-</para>
-
-<para>
- Contrairement à <envar>SLONYNODES</envar>, qui est essentielle pour
- <emphasis>tous</emphasis> les scripts de génération <xref linkend="slonik"/>,
- celle-ci n'est nécessaire que lorsqu'on exécute <filename>create_set</filename>
- car il s'agit du seul script qui contrôle le placement des tables dans les
- différents ensembles de réplication.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_build_env</title>
-<indexterm><primary>slonik_build_env</primary></indexterm>
-
-<para>
- Cette commande interroge la base de données et produit un résultat qui peut
- être utilisé dans <filename>slon_tools.conf</filename>, notamment :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- une série d'appel à <function>add_node()</function> pour configurer le
- cluster
- </para>
- </listitem>
-
- <listitem>
- <para>
- les tableaux <envar>@KEYEDTABLES</envar>, <envar>@SERIALT</envar>
- et <envar>@SEQUENCES</envar>
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-<sect3>
-<title>slonik_print_preamble</title>
-
-<para>
- Cette commande produit simplement le <quote>préambule</quote> qui est
- nécessaire à chaque script slonik. En fait, elle fournit un
- <quote>squelette</quote> de script slonik qui ne fait pas d'action
- particulière.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_create_set</title>
-
-<para>
- Cette commande nécessite que les variables <envar>SLONYSET</envar> et
- <envar>SLONYNODES</envar> soient configurées. Elle permet de produire
- le script <command>slonik</command> qui configure un ensemble de
- réplication en décrivant les tables et les séquences qui seront
- répliquées.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_drop_node</title>
-
-<para>
- Cette commande produit un script Slonik qui supprime un nœud du
- cluster &slony1;.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_drop_set</title>
-
-<para>
- Cette commande produit un script Slonik qui supprime un ensemble de
- réplication (<emphasis>c'est-à-dire</emphasis> un groupe de tables et de
- séquences).
-</para>
-
-</sect3>
-
-<sect3 id="slonik-drop-table">
-<title>slonik_drop_table</title>
-
-<para>
- Cette commande produit un script Slonik qui supprime une table de la réplication.
- Elle nécessite en entrée l'identifiant de la table (disponible dans la table
- <envar>sl_table</envar>).
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_execute_script</title>
-
-<para>
- Cette commande produit un script pour effectuer des changements DDL sur un
- ensemble de réplication.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_failover</title>
-
-<para>
- Cette commande produit un script qui demande une bascule d'urgence entre un
- nœud mort et une nouvelle origine.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_init_cluster</title>
-
-<para>
- Cette commande produit un script Slonik qui intialise un cluster &slony1;
- tout entier, y compris les nœuds, les voies de communications et les
- voies d'écoute.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_merge_sets</title>
-
-<para>
- Cette commande produit un script Slonik qui fusionne deux ensembles de
- réplication.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_move_set</title>
-
-<para>
- Cette commande produit un script Slonik qui déplace l'origine d'un ensemble de
- réplication vers un autre nœud.
-</para>
-
-</sect3>
-
-<sect3>
-<title>réplication_test</title>
-
-<para>
- Ce script vérifie que &slony1; réplique correctement les données.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_restart_node</title>
-
-<para>
- Cette commande produit un script Slonik qui demande le redémarrage d'un
- nœud. Elle était particulièrement utile avant la version 1.0.5,
- lorsque les nœuds étaient bloqués suite à la mort du démon slon.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_restart_nodes</title>
-
-<para>
- Cette commande produit un script Slonik qui redémarre tous les nœuds
- du cluster. Elle n'est pas très utile.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slony_show_configuration</title>
-
-<para>
- Cette commande affiche la configuration de l'environnement (c'est-à-dire
- la variable <envar>SLONYNODES</envar>).
-</para>
-
-</sect3>
-
-<sect3>
-<title>slon_kill</title>
-
-<para>
- Cette commande tue le chien de garde slony et tous les démons slon pour un
- ensemble de réplication donné. Elle ne fonctionne que si ces processus
- fonctionnent sur l'hôte local, bien sûr !
-</para>
-
-</sect3>
-
-<sect3>
-<title>slon_start</title>
-
-<para>
- Cette commande démarre le démon slon pour un cluster et un nœud donnés,
- elle utilise le chien de garde slon_watchdog pour s'assurer qu'il fonctionne.
-</para>
-
-</sect3>
-
-<sect3 id="slonwatchdog">
-<title>slon_watchdog</title>
-
-<para>
- Processus utilisé par <command>slon_start</command>.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slon_watchdog2</title>
-
-<para>
- Ce script est un chien de garde plus malin ; il surveille un nœud
- donné et relance le processus slon s'il constate qu'aucune modification ne
- s'est produite depuis 20 minutes ou plus.
-</para>
-
-<para>
- Ceci est utile lorsqu'une connexion réseau est instable et que le démon slon
- s'arrête sans crier gare.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_store_node</title>
-
-<para>
- Cette commande ajoute un nœud dans un cluster.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_subscribe_set</title>
-
-<para>
- Ce script génère un script Slonik script pour abonner un nœud donné à
- un ensemble donné.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_uninstall_nodes</title>
-
-<para>
- Cette commande parcourt le cluster et supprime le schéma &slony1; sur tous
- les nœuds. Vous pouvez utiliser cet outil si vous souhaitez détruire
- la réplication sur l'ensemble du cluster. Il s'agit d'un script
- <emphasis>TRÈS</emphasis> dangereux !
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_unsubscribe_set</title>
-
-<para>
- Cette commande produit un script Slonik qui désabonne un nœud d'un
- ensemble de réplication.
-</para>
-
-</sect3>
-
-<sect3>
-<title>slonik_update_nodes</title>
-
-<para>
- Cette commande produit un script Slonik qui incite tous les nœuds
- à mettre à jour les fonctions &slony1;. Elle est utile lorsque l'on effectue
- un changement de version de &slony1;.
-</para>
-
-</sect3>
-
-</sect2>
-
-<sect2 id="mkslonconf"><title>mkslonconf.sh</title>
-<indexterm><primary>générer le fichier slon.conf pour &slony1;</primary></indexterm>
-
-<para>
- Ce script shell est conçu pour parcourir un cluster &slony1; et produire un
- ensemble de fichiers <filename>slon.conf</filename> qui pourront être
- utilisés via l'option <command>slon -f slon.conf</command>.
-</para>
-
-<para>
- Lorsque toute la configuration est placée dans un fichier pour chaque &lslon;,
- on peut alors facilement les invoquer, sans risquer d'oublier l'option
- <command>-a</command>, ce qui peut provoquer le crash d'un nœud en mode
- <link linkend="logshipping">log shipping</link>.
-</para>
-
-<para>
- Pour lancer le script, il faut configurer l'environnement de la manière
- suivante :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Tout d'abord, l'environnement doit être configuré avec les paramètres
- adéquats pour que libpq puisse se connecter à une des bases de données
- du cluster. Vous devez donc définir une combinaison parmi les variables
- d'environnement suivantes :
- </para>
-
- <itemizedlist>
- <listitem><para><envar>PGPORT</envar></para></listitem>
- <listitem><para><envar>PGDATABASE</envar></para></listitem>
- <listitem><para><envar>PGHOST</envar></para></listitem>
- <listitem><para><envar>PGUSER</envar></para></listitem>
- <listitem><para><envar>PGSERVICE</envar></para></listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- <envar>SLONYCLUSTER</envar> - le nom du cluster &slony1; qui doit être
- <quote>parcouru</quote>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>MKDESTINATION</envar> - un répertoire qui accueillera la
- configuration ; le script crée un dossier
- <filename>MKDESTINATION/$SLONYCLUSTER/conf</filename> pour les fichiers
- de configuration des démons &lslon; et un dossier
- <filename>MKDESTINATION/$SLONYCLUSTER/pid</filename> pour que &lslon; y
- stocke les fichiers PID.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>LOGHOME</envar> - un répertoire qui accueillera les fichiers de
- log ; un dossier nommé
- <command>$LOGHOME/$SLONYCLUSTER/node[numéro]</command> sera créé pour
- chaque nœud.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Pour chaque <quote>nouveau</quote> nœud qu'il découvre, ce script va
- créer un nouveau fichier de configuration &lslon;.
-</para>
-
-<warning>
- <para>
- Il est important de préciser que ce script présente quelques particularités
- qu'il faut connaître, mais aucune n'est vraiment surprenante.
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- Le DSN est positionné à la plus petite valeur trouvé pour chaque
- nœud dans le table <envar>sl_path</envar>. Vous devrez
- probablement modifier cette valeur.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Plusieurs paramètres sont initialisés avec leur valeur par défaut ;
- Vous devrez probablement les réajuster à la main.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si vous exécutez les processus &lslon; sur de multiples nœuds
- (<emphasis>par exemple</emphasis> - si vous utilisez &slony1; à travers
- un réseau WAN), ce script va joyeusement créer des fichiers de
- configuration pour des &lslon;s que vous comptez lancer sur un hôte
- différent.
- </para>
-
- <para>
- Vérifiez bien les nœuds configurés avant de redémarrer les &lslon;s.
- </para>
-
- <para>
- En général, cela provoque des inconvénients mineurs comme, par exemple,
- un &lslon; fonctionnant de manière inapproprié, échouant suite à un
- problème de connectivité (ce qui ne provoque pas de dégâts !), ou
- fonctionnant moins efficacement vu qu'il se trouve du mauvais coté du
- <quote>tuyau</quote>.
- </para>
-
- <para>
- D'un autre côté, si vous faites fonctionner un nœud en mode log
- shipping sur le site distant, l'arrivée d'un &lslon; qui <emphasis>ne
- collecte pas</emphasis> les logs peut ruiner une semaine complète
- d'activité.
- </para>
- </listitem>
- </itemizedlist>
-</warning>
-
-<para>
- Les fichiers produits par <filename>mkslonconf.sh</filename> sont
- spécifiquement conçus pour gérer des &lslon;s sur de multiples clusters avec
- le script décrit dans la section suivante...
-</para>
-
-</sect2>
-
-<sect2 id="launchclusters">
-<title>launch_clusters.sh</title>
-<indexterm><primary>lancer un cluster &slony1; cluster en utilisant les fichiers slon.conf</primary></indexterm>
-
-<para>
- Voici un autre script shell qui utilise la configuration produite par
- <filename>mkslonconf.sh</filename> et qui peut être utilisé lors du démarrage
- du système, à la suite des processus <filename>rc.d</filename> ou dans un
- processus cron, pour s'assurer que les processus &lslon; fonctionnent.
-</para>
-
-<para>
- Il utilise les variables d'environnement suivantes :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <envar>PATH</envar> qui doit contenir, de préférence au début, le chemin
- vers les binaires &lslon; qui doivent être exécutés.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>SLHOME</envar> indique le répertoire <quote>home</quote> qui
- contient les fichiers de configuration de &lslon; ; ces fichiers
- doivent être rangés en sous-répertoires, un pour chaque cluster, avec
- un nom de fichier du type <filename>node1.conf</filename>,
- <filename>node2.conf</filename> et ainsi de suite.
- </para>
-
- <para>
- Le script utilise la commande <command>find $SLHOME/$cluster/conf
- -name "node[0-9]*.conf"</command> pour trouver les fichiers de
- configuration &lslon;.
- </para>
-
- <para>
- Si vous déplacez ces fichiers ou si vous les renommez, ils ne seront pas
- trouvés ; c'est une façon très simple de supprimer des nœuds.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>LOGHOME </envar> indique le répertoire <quote>home</quote> pour le
- stockage des journaux applicatifs.
- </para>
-
- <para>
- Ce script ne nécessite pas l'utilisation du gestionnaire de journaux
- applicatifs d'Apache, sachant que &postgres; version 8 gère lui-même la
- rotation des journaux applicatifs, il semble inopportun de garder une
- dépendance à une <quote>technologie</quote> de rotation spécifique.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>CLUSTERS</envar> est la liste des clusters &slony1; qui sont
- gérés.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- En pratique, vous pouvez lancer ce programme toutes les cinq minutes, et il
- relancera tous les processus &lslon; manquants.
-</para>
-
-</sect2>
-
-<sect2 id="extractschema">
-<title><filename>slony1_extract_schema.sh</filename></title>
-<indexterm><primary>script - slony1_extract_schema.sh</primary></indexterm>
-
-<para>
- Si vous souhaitez créer un nouveau nœud, après la création du cluster,
- le script <filename>slony1_extract_schema.sh</filename> vous aidera dans
- cette tache.
-</para>
-
-<para>
- La commande d'exécution peut ressembler à la ligne suivante :
-</para>
-
-<para>
- <command>PGPORT=5881 PGHOST=master.int.example.info ./slony1_extract_schema.sh payroll payroll temppayroll</command>
-</para>
-
-<para>
- Elle réalise les actions suivantes :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Elle fait un dump du schéma du nœud origine, y compris les
- informations du schéma du cluster &slony1;.
- </para>
-
- <para>
- Notons que les variables d'environnement <envar>PGPORT</envar> et
- <envar>PGHOST</envar> fournissent des informations additionnelles sur
- l'emplacement de la base de données.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Ces informations sont chargées dans une table temporaire fraîchement
- créée : <envar>temppayroll</envar>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Les OID de table et de séquence dans les tables &slony1; sont corrigées
- pour pointer vers la configuration de la base temporaire.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Un script slonik est lancé pour effectuer l'action <xref
- linkend="stmtuninstallnode"/> sur la base temporaire. Ceci élimine toutes
- les tables et le schéma spécifique à &slony1;, et supprime les triggers
- &slony1; des tables répliquées.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Enfin, la commande <application>pg_dump</application> est lancée sur la
- base temporaire, et produit une copie nettoyée du schéma sur la sortie
- standard.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-<sect2>
-<title>slony-cluster-analysis</title>
-<indexterm><primary>script - slony-cluster-analysis</primary></indexterm>
-
-<para>
- Si vous exploitez beaucoup de bases répliquées, au sein de plusieurs clusters
- &slony1;, il peut devenir pénible de suivre et de documenter votre
- architecture. L'outil suivant peut vous y aider.
-</para>
-
-<para>
- <application>slony-cluster-analysis.sh</application> est un script shell
- conçu pour fournir une analyse à long terme de la configuration d'un cluster
- &slony1;. Vous passez les variables d'environnement
- <application>libpq</application> habituelles (<envar>PGHOST</envar>,
- <envar>PGPORT</envar>, <envar>PGDATABASE</envar> et ainsi de suite) pour se
- connecter à un membre du cluster &slony1;, et passer le nom du cluster comme
- argument.
-</para>
-
-<para>
- Le script effectue alors les actions suivantes :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Lancement d'une séries de requêtes sur les tables &slony1; pour obtenir
- la liste des nœuds, des voies de communication, des ensembles de
- réplication et des tables.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Ces données sont stockées dans un fichier temporaire situé dans
- <filename>/tmp</filename>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Une comparaison est effectuée entre la configuration présente et la
- configuration trouvée lors de la dernière exécution du script. Si la
- configuration a changé, un courriel contenant les différences (produit
- avec <application>diff</application>) est envoyée à l'adresse spécifiée.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si la configuration a changé, l'ancien fichier de configuration est
- renommé pour indiquer quand le script a remarqué le changement.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Finalement, la configuration courante est stockée dans le dossier
- <envar>LOGDIR</envar> dans un fichier nommé
- <filename>cluster.last</filename>.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Il existe un exemple de script <quote>d'encapsulation</quote>,
- <filename>slony-cluster-analysis-mass.sh</filename>, qui permet de pointer
- vers un ensemble de clusters &slony1;.
-</para>
-
-<para>
- Ceci devrait simplifier la taches des administrateurs ("DBA") sur deux
- plans :
-</para>
-
-<itemizedlist>
-
- <listitem>
- <para>la documentation de l'état courant du système </para>
- </listitem>
-
- <listitem>
- <para>la surveillance des changements de configuration.</para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-<sect2 id="configurereplication">
-<title>Génération de scripts slonik avec <filename>configure-replication.sh</filename></title>
-<indexterm><primary>générer des scripts slonik pour un cluster</primary></indexterm>
-
-<para>
- Le script <filename>configure-replication.sh</filename>, situé dans le
- répertoire <filename>outil</filename>, est conçu pour automatiser la
- génération de scripts slonik de configuration de la réplication. La
- configuration de ce script reprend la même approche que le <xref
- linkend="testbed"/>.
-</para>
-
-<para>
- Ce script utilise beaucoup (peut-être énormément, si votre configuration est
- particulièrement complexe) de variables d'environnement pour déterminer la
- forme de la configuration du cluster. Il utilise massivement les valeurs par
- défaut et, dans la plupart des cas, peu de valeurs doivent être positionnées
- afin d'obtenir une configuration viable.
-</para>
-
-<sect3>
-<title>Valeurs globales</title>
-
-<para>
- Certaines valeurs sont utilisées universellement partout sur le cluster :
-</para>
-
-<variablelist>
- <varlistentry>
- <term><envar>CLUSTER</envar></term>
- <listitem><para>Nom du cluster Slony-I</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><envar>NUMNODES</envar></term>
- <listitem><para>Nombre de nœuds à configurer</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><envar>PGUSER</envar></term>
- <listitem><para>Nom du super-utilisateur qui contrôle la réplication</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><envar>PGPORT</envar></term>
- <listitem><para>Numéro du port par défaut</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><envar>PGDATABASE</envar></term>
- <listitem><para>Nom de la base de données par défaut</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><envar>TABLES</envar></term>
- <listitem>
- <para>
- Liste de noms complets de tables (<emphasis>par exemple</emphasis> - un
- nom incluant le schéma tel que <command>public.ma_table</command>)
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><envar>SEQUENCES</envar></term>
- <listitem>
- <para>
- Liste de noms complets de séquences (<emphasis>par exemple</emphasis>
- - un nom incluant le schéma tel que <command>public.ma_sequence</command>)
- </para>
- </listitem>
- </varlistentry>
-</variablelist>
-
-<para>
- Des valeurs par défauts sont fournies pour <emphasis>chacune</emphasis> de
- ces valeurs, si bien que si vous lancez <filename>configure-replication.sh</filename>
- sans configurer aucune variable d'environnement, vous obtiendrez un ensemble
- de scripts slonik. Bien sûr, ils ne correspondront pas aux bases que vous
- voudrez configurer...
-</para>
-
-</sect3>
-
-<sect3>
-<title>Valeur spécifique à un nœud</title>
-
-<para>
- Pour chaque nœ, il y a également quatre variables d'environnement ;
- pour le nœud 1 :
-</para>
-
-<variablelist>
- <varlistentry>
- <term><envar>DB1</envar></term>
- <listitem><para>La base de données à laquelle les scripts doivent se connecter</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><envar>USER1</envar></term>
- <listitem><para>Le super-utilisateur utilisé pour la connexion</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><envar>PORT1</envar></term>
- <listitem><para> Le port</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><envar>HOST1</envar></term>
- <listitem><para>L'hôte</para></listitem>
- </varlistentry>
-</variablelist>
-
-<para>
- Il est très probable que <envar>DB*</envar>, <envar>USER*</envar> et
- <envar>PORT*</envar> correspondent aux variables globales
- <envar>PGDATABASE</envar>, <envar>PGUSER</envar> et
- <envar>PGPORT</envar> décrites précédemment ; conserver cette
- correspondance est souvent une bonne chose.
-</para>
-
-<para>
- En revanche, les valeurs <envar>HOST*</envar> doivent être définies
- explicitement pour <envar>HOST1</envar>, <envar>HOST2</envar>, ...
- car il n'est pas très malin de mettre en place un système de réplication
- si toutes les bases redondantes se trouvent sur le même serveur !
-</para>
-
-</sect3>
-
-<sect3>
-<title>Les scripts slonik générés</title>
-
-<para>
- Les scripts de configuration slonik sont générés dans un répertoire temporaire
- à l'intérieur de <filename>/tmp</filename>. Leur usage est le suivant :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <filename>preamble.slonik</filename> est un fichier <quote>préambule</quote>
- contenant les informations de connexion utilisées par les autres scripts.
- </para>
-
- <para>
- Vérifier attentivement celui-ci ; vous pourrez le réutiliser pour
- les futures opérations de maintenance que vous effectuerez sur le cluster.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <filename>create_set.slonik</filename>
- </para>
-
- <para>
- Ce script est le premier qu'il faut lancer ; il configure les
- nœuds spécifiés en nœud &slony1;, en y ajoutant les tables
- et les autres objets spécifiques de &slony1;.
- </para>
-
- <para>
- Vous pouvez/devez lancer les processus slon juste après cette étape.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <filename>store_paths.slonik</filename>
- </para>
-
- <para>
- Le second script à exécuter ; il indique comment les &lslon;
- doivent communiquer entre eux. Ce script suppose que tous les &lslon;
- peuvent parler à tous les nœuds, ce qui n'est peut-être pas exact
- dans un environnement peuplé de pare-feu complexes. Si cette supposition
- n'est pas correcte, vous devez modifier ce script pour corriger les voies
- de communications.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <filename>create_set.slonik</filename>
- </para>
-
- <para>
- Ce script configure l'ensemble de réplication composé de toutes les
- tables et les séquences présentes dans le schéma de la base de données
- de votre application.
- </para>
-
- <para>
- Lorsque vous lancez ce script, la seule action menée est l'ajout de
- triggers sur le nœud origine (nœud #1) qui vont commencer
- à collecter les mises à jours. La réplication ne commencera qu'à l'étape
- #5...
- </para>
-
- <para>
- Il y a deux suppositions dans ce scripts qui peuvent ne pas être valides
- dans certaines circonstances :
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- que toutes les tables et les séquences soit répliquées
- </para>
-
- <para>
- Ceci n'est pas valide lorsque de nouvelles tables sont ajoutée dans
- votre schéma et qu'elles ne sont pas ajoutées dans la liste
- <envar>TABLES</envar>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- que toutes les tables sont définies avec des clefs primaires
- </para>
-
- <para>
- La bonne pratique est de toujours créer et utiliser de vraies clefs
- primaires. Si vous avez des tables qui nécessitent de choisir une
- clef primaire candidate ou qui nécessite la création d'une clef
- additionnelle avec la commande <xref linkend="stmttableaddkey"/>,
- vous devez modifier ce script à la main pour l'accommoder.
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- <filename>subscribe_set_2.slonik</filename>
- </para>
-
- <para>
- et 3, 4, 5, si vous configurez d'autres nœuds...
- </para>
-
- <para>
- Ceci est l'étape qui <quote>déclenche</quote> la réplication.
- </para>
-
- <para>
- Ce script fait la supposition que tous les nœuds abonnés voudront
- s'abonner directement au nœud origine. Si vous souhaitez mettre en
- place des <quote>sous-clusters</quote> avec peut-être un nœud
- maître dans chaque centre de données, vous devez modifier ces scripts.
- </para>
-
- <para>
- Les processus slon doivent fonctionner au moment où vous réalisez cette
- étape. Il est absurde de lancer ces scripts lorsque ce n'est pas le cas.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-</sect2>
-
-<sect2 id="bsd-ports-profile">
-<title><filename>slon.in-profiles</filename></title>
-<subtitle>profiles dans le style d'Apache pour FreeBSD <filename>ports/databases/slony/*</filename></subtitle>
-<indexterm>
- <primary>profiles dans le style d'Apache pour FreeBSD</primary>
- <secondary>FreeBSD</secondary>
-</indexterm>
-
-<para>
- Dans le répertoire <filename>tools</filename>, le script
- <filename>slon.in-profiles</filename> permet de lancer des instances &lslon;
- lors du démarrage du système. Il est conçu pour interagir avec le système des
- ports de FreeBSD.
-</para>
-
-</sect2>
-
-<sect2 id="duplicate-node">
-<title><filename>duplicate-node.sh</filename></title>
-<indexterm><primary>dupliquer un nœud</primary></indexterm>
-
-<para>
- Dans le répertoire <filename>tools</filename>, le script
- <filename>duplicate-node.sh</filename> aide à créer un nouveau nœud
- en dupliquant un des nœuds du cluster.
-</para>
-
-<para>
- Ce script attend les paramètres suivants :
-</para>
-
-<itemizedlist>
- <listitem><para>le nom du cluster ;</para></listitem>
- <listitem><para>le numéro du nouveau nœud ;</para></listitem>
- <listitem><para>le nœud origine ;</para></listitem>
- <listitem><para>le nœud répliqué ;</para></listitem>
- <listitem><para>le nouveau nœud ;</para></listitem>
-</itemizedlist>
-
-<para>
- Pour chaque nœud spécifié, le script permet de préciser les paramètres
- de type <function>libpq</function> pour <envar>PGHOST</envar>,
- <envar>PGPORT</envar>, <envar>PGDATABASE</envar> et <envar>PGUSER</envar>. Le
- fichier <filename>.pgpass</filename> peut être utilisé pour le stockage des
- mots de passe, ce qui est généralement considéré comme une bonne pratique.
- Lorsqu'elles ne sont pas définies, ces valeurs peuvent hériter des variables
- d'environnement <function>libpq</function>, ce qui est pratique quand on
- réalise des tests. Toutefois, lorsque que ce script est utilisé <quote>de
- manière brutale</quote>, il est souvent nécessaire de définir les 14
- paramètres disponibles.
-</para>
-
-<para>
- Ce script prépare des fichiers, placés dans <filename>/tmp</filename>, et
- annonce le nom du répertoire qu'il a créé pour les scripts SQL et &lslonik;
- de configuration du nouveau nœud.
-</para>
-
-<itemizedlist>
- <listitem>
- <para><filename>schema.sql</filename></para>
- <para>
- Ce script est tiré du nœud origine et contient le schéma de données
- <quote>originel</quote> qui doit être appliqué au départ.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>slonik.preamble</filename></para>
- <para>
- Ce fichier <quote>preambule</quote> est utilisé par l'ensemble des scripts
- slonik ci-dessous.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>step1-storenode.slonik</filename></para>
- <para>
- Un script &lslonik; qui configure le nouveau nœud.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>step2-storepath.slonik</filename></para>
- <para>
- Un script &lslonik; qui met en place des voies de communication entre
- le nœud fournisseur et le nouveau nœud.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>step3-subscribe-sets.slonik</filename></para>
- <para>
- Un script &lslonik; qui demande la souscription à tous les ensembles de
- réplication.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Lorsque l'on effectue un test, cela est suffisant pour faire fonctionner un
- nouveau nœud. La configuration ne doit pas forcément correspondre à une
- configuration finale, notamment :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Il est souhaitable de construire des voies de communication
- supplémentaires afin d'assurer leur redondance.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Les scripts générés supposent que le nouveau nœud doit être un
- nœud transmetteur (« forwarding »), ce qui n'est pas
- forcément vrai.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Il est parfois souhaitable, une fois que le processus d'abonnement est
- réalisé complètement, de modifier les abonnements.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/adminscripts.xml (from rev 1244, traduc/trunk/slony/adminscripts.xml)
===================================================================
--- traduc/tags/slony_1_2_12/adminscripts.xml (rev 0)
+++ traduc/tags/slony_1_2_12/adminscripts.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,1076 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="adminscripts">
+<title>Scripts d'administration</title>
+<indexterm><primary>scripts d'administration de &slony1;</primary></indexterm>
+
+<para>
+ Un certain nombre de scripts ont été développés tout au long de l'histoire de
+ &slony1; pour aider les utilisateurs à gérer leurs clusters. Cette section
+ ainsi que celle sur le <xref linkend="monitoring"/> et la <xref
+ linkend="maintenance"/> décrit leur utilisation.
+</para>
+
+<sect2 id="altperl">
+<title>Les scripts altperl</title>
+<indexterm><primary>Script altperl pour &slony1;</primary></indexterm>
+
+<para>
+ Il existe un ensemble de scripts qui simplifie l'administration de plusieurs
+ instances &slony1;. Ces scripts supportent une nombre variable de nœuds.
+ Ils peuvent être installés pendant le processus d'installation :
+</para>
+
+<para>
+ <command>./configure --with-perltools</command>
+</para>
+
+<para>
+ Ceci va produire un certain nombre de scripts avec le préfixe
+ <command>slonik_</command>. Ils éliminent les risques de confusion en se
+ référençant à un fichier central de configuration qui contient les détails
+ de la configuration de votre site. Un exemple documenté de ce fichier est
+ fourni dans <filename>altperl/slon_tools.conf-sample</filename>. La plupart
+ dispose également d'une aide en ligne grâce à l'option "--help", ce qui les
+ rend plus facile à prendre en main et à utiliser.
+</para>
+
+<para>
+ La plupart des scripts de génération Slonik utilise la sortie STDOUT. Pendant
+ un temps, les commandes étaient passées directement à <xref linkend="slonik"/>
+ pour qu'il les exécute. Malheureusement, il s'agit d'une méthode trop
+ <quote>agressive</quote> car de légères coquilles dans la ligne de commande
+ peuvent conduire, dans certains cas, à des situations calamiteuses. Tout
+ administrateur qui se respecte doit relire le script
+ <emphasis>avant</emphasis> de l'envoyer à <xref linkend="slonik"/>.
+</para>
+
+<sect3>
+<title>Gestion de multiples clusters</title>
+<indexterm><primary>gérer de multiples clusters avec les outils altperl</primary></indexterm>
+
+<para>
+ La variable d'environnement <envar>SLONYNODES</envar> est utilisée pour
+ déterminer le fichier de configuration Perl qui sera utilisé pour contrôler
+ les nœuds du cluster &slony1;. Si elle n'est pas fournie, le fichier
+ <filename>slon_tools.conf</filename> situé dans l'emplacement par défaut
+ sera utilisé.
+</para>
+
+<para>
+ Voici la liste des variables qui peuvent être configurées :
+ <itemizedlist>
+ <listitem>
+ <para>
+ <envar>$CLUSTER_NAME</envar>=orglogs; # Quel est le nom du cluster de
+ réplication ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>$LOGDIR</envar>='/opt/OXRS/log/LOGDBS'; # Quel est le répertoire
+ des logs ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>$APACHE_ROTATOR</envar>="/opt/twcsds004/OXRS/apache/rotatelogs";
+ # Si ce paramètre est défini, il indique où trouver le gestionnaire de
+ gestion des traces d'Apache
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>foldCase</envar> # Si la valeur est 1, les noms d'objet (y
+ compris les noms de schéma) sont transformés en minuscule. Par
+ défaut, les noms d'objets restent inchangés. Notons que &postgres;
+ lui-même transforme les noms d'objets en minuscule. Si vous créez
+ une table avec la commande <command>CREATE TABLE MA_TABLE (Id INTEGER,
+ MoNChamp text);</command>, le résultat sera équivalent à
+ <command>create table ma_table (id integer, monchamp text);</command>,
+ le nom de la table et celui de ses champs seront transformés en
+ minuscule.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
+
+<para>
+ Vous pouvez ensuite définir un ensemble de nœuds qui participeront à
+ la réplication en utilisant plusieurs appels à la fonction
+ <function>add_node()</function>.
+</para>
+
+<para>
+ <command>add_node (host => '10.20.30.40', dbname => 'orglogs',
+ port => 5437, user => 'postgres', node => 4, parent => 1);</command>
+</para>
+
+<para>
+ Les paramètres de la fonction <function>add_node()</function> sont les
+ suivants :
+</para>
+
+<programlisting>my %PARAMS = (host=> undef, # nom de l'hôte
+ dbname => 'template1', # nom de la base
+ port => 5432, # numéro du port
+ user => 'postgres', # utilisateur de la connexion
+ node => undef, # numéro du nœud
+ password => undef, # mot de passe de l'utilisateur
+ parent => 1, # l'identifiant du nœud père
+ noforward => undef # ce nœud doit-il retransmettre les modifications ?
+ sslmode => undef # mode SSL - détermine la priorité
+ # d'utilisation de la couche SSL
+ # = disable,allow,prefer,require
+);</programlisting>
+
+</sect3>
+
+<sect3>
+<title>Configuration d'un ensemble de réplication</title>
+<indexterm><primary>cluster.set1 - configuration d'un ensemble de réplication
+pour les outils Perl</primary></indexterm>
+
+<para>
+ La variable d'environnement UNIX <envar>SLONYSET</envar> est utilisée pour
+ déterminer le fichier de configuration à lire pour connaître les objets qui
+ sont contenus dans un ensemble donné.
+</para>
+
+<para>
+ Contrairement à <envar>SLONYNODES</envar>, qui est essentielle pour
+ <emphasis>tous</emphasis> les scripts de génération <xref linkend="slonik"/>,
+ celle-ci n'est nécessaire que lorsqu'on exécute <filename>create_set</filename>
+ car il s'agit du seul script qui contrôle le placement des tables dans les
+ différents ensembles de réplication.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_build_env</title>
+<indexterm><primary>slonik_build_env</primary></indexterm>
+
+<para>
+ Cette commande interroge la base de données et produit un résultat qui peut
+ être utilisé dans <filename>slon_tools.conf</filename>, notamment :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ une série d'appel à <function>add_node()</function> pour configurer le
+ cluster
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ les tableaux <envar>@KEYEDTABLES</envar>, <envar>@SERIALT</envar>
+ et <envar>@SEQUENCES</envar>
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect3>
+
+<sect3>
+<title>slonik_print_preamble</title>
+
+<para>
+ Cette commande produit simplement le <quote>préambule</quote> qui est
+ nécessaire à chaque script slonik. En fait, elle fournit un
+ <quote>squelette</quote> de script slonik qui ne fait pas d'action
+ particulière.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_create_set</title>
+
+<para>
+ Cette commande nécessite que les variables <envar>SLONYSET</envar> et
+ <envar>SLONYNODES</envar> soient configurées. Elle permet de produire
+ le script <command>slonik</command> qui configure un ensemble de
+ réplication en décrivant les tables et les séquences qui seront
+ répliquées.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_drop_node</title>
+
+<para>
+ Cette commande produit un script Slonik qui supprime un nœud du
+ cluster &slony1;.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_drop_set</title>
+
+<para>
+ Cette commande produit un script Slonik qui supprime un ensemble de
+ réplication (<emphasis>c'est-à-dire</emphasis> un groupe de tables et de
+ séquences).
+</para>
+
+</sect3>
+
+<sect3 id="slonik-drop-table">
+<title>slonik_drop_table</title>
+
+<para>
+ Cette commande produit un script Slonik qui supprime une table de la réplication.
+ Elle nécessite en entrée l'identifiant de la table (disponible dans la table
+ <envar>sl_table</envar>).
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_execute_script</title>
+
+<para>
+ Cette commande produit un script pour effectuer des changements DDL sur un
+ ensemble de réplication.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_failover</title>
+
+<para>
+ Cette commande produit un script qui demande une bascule d'urgence entre un
+ nœud mort et une nouvelle origine.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_init_cluster</title>
+
+<para>
+ Cette commande produit un script Slonik qui intialise un cluster &slony1;
+ tout entier, y compris les nœuds, les voies de communications et les
+ voies d'écoute.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_merge_sets</title>
+
+<para>
+ Cette commande produit un script Slonik qui fusionne deux ensembles de
+ réplication.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_move_set</title>
+
+<para>
+ Cette commande produit un script Slonik qui déplace l'origine d'un ensemble de
+ réplication vers un autre nœud.
+</para>
+
+</sect3>
+
+<sect3>
+<title>réplication_test</title>
+
+<para>
+ Ce script vérifie que &slony1; réplique correctement les données.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_restart_node</title>
+
+<para>
+ Cette commande produit un script Slonik qui demande le redémarrage d'un
+ nœud. Elle était particulièrement utile avant la version 1.0.5,
+ lorsque les nœuds étaient bloqués suite à la mort du démon slon.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_restart_nodes</title>
+
+<para>
+ Cette commande produit un script Slonik qui redémarre tous les nœuds
+ du cluster. Elle n'est pas très utile.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slony_show_configuration</title>
+
+<para>
+ Cette commande affiche la configuration de l'environnement (c'est-à-dire
+ la variable <envar>SLONYNODES</envar>).
+</para>
+
+</sect3>
+
+<sect3>
+<title>slon_kill</title>
+
+<para>
+ Cette commande tue le chien de garde slony et tous les démons slon pour un
+ ensemble de réplication donné. Elle ne fonctionne que si ces processus
+ fonctionnent sur l'hôte local, bien sûr !
+</para>
+
+</sect3>
+
+<sect3>
+<title>slon_start</title>
+
+<para>
+ Cette commande démarre le démon slon pour un cluster et un nœud donnés,
+ elle utilise le chien de garde slon_watchdog pour s'assurer qu'il fonctionne.
+</para>
+
+</sect3>
+
+<sect3 id="slonwatchdog">
+<title>slon_watchdog</title>
+
+<para>
+ Processus utilisé par <command>slon_start</command>.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slon_watchdog2</title>
+
+<para>
+ Ce script est un chien de garde plus malin ; il surveille un nœud
+ donné et relance le processus slon s'il constate qu'aucune modification ne
+ s'est produite depuis 20 minutes ou plus.
+</para>
+
+<para>
+ Ceci est utile lorsqu'une connexion réseau est instable et que le démon slon
+ s'arrête sans crier gare.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_store_node</title>
+
+<para>
+ Cette commande ajoute un nœud dans un cluster.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_subscribe_set</title>
+
+<para>
+ Ce script génère un script Slonik script pour abonner un nœud donné à
+ un ensemble donné.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_uninstall_nodes</title>
+
+<para>
+ Cette commande parcourt le cluster et supprime le schéma &slony1; sur tous
+ les nœuds. Vous pouvez utiliser cet outil si vous souhaitez détruire
+ la réplication sur l'ensemble du cluster. Il s'agit d'un script
+ <emphasis>TRÈS</emphasis> dangereux !
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_unsubscribe_set</title>
+
+<para>
+ Cette commande produit un script Slonik qui désabonne un nœud d'un
+ ensemble de réplication.
+</para>
+
+</sect3>
+
+<sect3>
+<title>slonik_update_nodes</title>
+
+<para>
+ Cette commande produit un script Slonik qui incite tous les nœuds
+ à mettre à jour les fonctions &slony1;. Elle est utile lorsque l'on effectue
+ un changement de version de &slony1;.
+</para>
+
+</sect3>
+
+</sect2>
+
+<sect2 id="mkslonconf"><title>mkslonconf.sh</title>
+<indexterm><primary>générer le fichier slon.conf pour &slony1;</primary></indexterm>
+
+<para>
+ Ce script shell est conçu pour parcourir un cluster &slony1; et produire un
+ ensemble de fichiers <filename>slon.conf</filename> qui pourront être
+ utilisés via l'option <command>slon -f slon.conf</command>.
+</para>
+
+<para>
+ Lorsque toute la configuration est placée dans un fichier pour chaque &lslon;,
+ on peut alors facilement les invoquer, sans risquer d'oublier l'option
+ <command>-a</command>, ce qui peut provoquer le crash d'un nœud en mode
+ <link linkend="logshipping">log shipping</link>.
+</para>
+
+<para>
+ Pour lancer le script, il faut configurer l'environnement de la manière
+ suivante :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Tout d'abord, l'environnement doit être configuré avec les paramètres
+ adéquats pour que libpq puisse se connecter à une des bases de données
+ du cluster. Vous devez donc définir une combinaison parmi les variables
+ d'environnement suivantes :
+ </para>
+
+ <itemizedlist>
+ <listitem><para><envar>PGPORT</envar></para></listitem>
+ <listitem><para><envar>PGDATABASE</envar></para></listitem>
+ <listitem><para><envar>PGHOST</envar></para></listitem>
+ <listitem><para><envar>PGUSER</envar></para></listitem>
+ <listitem><para><envar>PGSERVICE</envar></para></listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>SLONYCLUSTER</envar> - le nom du cluster &slony1; qui doit être
+ <quote>parcouru</quote>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>MKDESTINATION</envar> - un répertoire qui accueillera la
+ configuration ; le script crée un dossier
+ <filename>MKDESTINATION/$SLONYCLUSTER/conf</filename> pour les fichiers
+ de configuration des démons &lslon; et un dossier
+ <filename>MKDESTINATION/$SLONYCLUSTER/pid</filename> pour que &lslon; y
+ stocke les fichiers PID.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>LOGHOME</envar> - un répertoire qui accueillera les fichiers de
+ log ; un dossier nommé
+ <command>$LOGHOME/$SLONYCLUSTER/node[numéro]</command> sera créé pour
+ chaque nœud.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Pour chaque <quote>nouveau</quote> nœud qu'il découvre, ce script va
+ créer un nouveau fichier de configuration &lslon;.
+</para>
+
+<warning>
+ <para>
+ Il est important de préciser que ce script présente quelques particularités
+ qu'il faut connaître, mais aucune n'est vraiment surprenante.
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Le DSN est positionné à la plus petite valeur trouvé pour chaque
+ nœud dans le table <envar>sl_path</envar>. Vous devrez
+ probablement modifier cette valeur.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Plusieurs paramètres sont initialisés avec leur valeur par défaut ;
+ Vous devrez probablement les réajuster à la main.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si vous exécutez les processus &lslon; sur de multiples nœuds
+ (<emphasis>par exemple</emphasis> - si vous utilisez &slony1; à travers
+ un réseau WAN), ce script va joyeusement créer des fichiers de
+ configuration pour des &lslon;s que vous comptez lancer sur un hôte
+ différent.
+ </para>
+
+ <para>
+ Vérifiez bien les nœuds configurés avant de redémarrer les &lslon;s.
+ </para>
+
+ <para>
+ En général, cela provoque des inconvénients mineurs comme, par exemple,
+ un &lslon; fonctionnant de manière inapproprié, échouant suite à un
+ problème de connectivité (ce qui ne provoque pas de dégâts !), ou
+ fonctionnant moins efficacement vu qu'il se trouve du mauvais coté du
+ <quote>tuyau</quote>.
+ </para>
+
+ <para>
+ D'un autre côté, si vous faites fonctionner un nœud en mode log
+ shipping sur le site distant, l'arrivée d'un &lslon; qui <emphasis>ne
+ collecte pas</emphasis> les logs peut ruiner une semaine complète
+ d'activité.
+ </para>
+ </listitem>
+ </itemizedlist>
+</warning>
+
+<para>
+ Les fichiers produits par <filename>mkslonconf.sh</filename> sont
+ spécifiquement conçus pour gérer des &lslon;s sur de multiples clusters avec
+ le script décrit dans la section suivante...
+</para>
+
+</sect2>
+
+<sect2 id="launchclusters">
+<title>launch_clusters.sh</title>
+<indexterm><primary>lancer un cluster &slony1; cluster en utilisant les fichiers slon.conf</primary></indexterm>
+
+<para>
+ Voici un autre script shell qui utilise la configuration produite par
+ <filename>mkslonconf.sh</filename> et qui peut être utilisé lors du démarrage
+ du système, à la suite des processus <filename>rc.d</filename> ou dans un
+ processus cron, pour s'assurer que les processus &lslon; fonctionnent.
+</para>
+
+<para>
+ Il utilise les variables d'environnement suivantes :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <envar>PATH</envar> qui doit contenir, de préférence au début, le chemin
+ vers les binaires &lslon; qui doivent être exécutés.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>SLHOME</envar> indique le répertoire <quote>home</quote> qui
+ contient les fichiers de configuration de &lslon; ; ces fichiers
+ doivent être rangés en sous-répertoires, un pour chaque cluster, avec
+ un nom de fichier du type <filename>node1.conf</filename>,
+ <filename>node2.conf</filename> et ainsi de suite.
+ </para>
+
+ <para>
+ Le script utilise la commande <command>find $SLHOME/$cluster/conf
+ -name "node[0-9]*.conf"</command> pour trouver les fichiers de
+ configuration &lslon;.
+ </para>
+
+ <para>
+ Si vous déplacez ces fichiers ou si vous les renommez, ils ne seront pas
+ trouvés ; c'est une façon très simple de supprimer des nœuds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>LOGHOME </envar> indique le répertoire <quote>home</quote> pour le
+ stockage des journaux applicatifs.
+ </para>
+
+ <para>
+ Ce script ne nécessite pas l'utilisation du gestionnaire de journaux
+ applicatifs d'Apache, sachant que &postgres; version 8 gère lui-même la
+ rotation des journaux applicatifs, il semble inopportun de garder une
+ dépendance à une <quote>technologie</quote> de rotation spécifique.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>CLUSTERS</envar> est la liste des clusters &slony1; qui sont
+ gérés.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ En pratique, vous pouvez lancer ce programme toutes les cinq minutes, et il
+ relancera tous les processus &lslon; manquants.
+</para>
+
+</sect2>
+
+<sect2 id="extractschema">
+<title><filename>slony1_extract_schema.sh</filename></title>
+<indexterm><primary>script - slony1_extract_schema.sh</primary></indexterm>
+
+<para>
+ Si vous souhaitez créer un nouveau nœud, après la création du cluster,
+ le script <filename>slony1_extract_schema.sh</filename> vous aidera dans
+ cette tache.
+</para>
+
+<para>
+ La commande d'exécution peut ressembler à la ligne suivante :
+</para>
+
+<para>
+ <command>PGPORT=5881 PGHOST=master.int.example.info ./slony1_extract_schema.sh payroll payroll temppayroll</command>
+</para>
+
+<para>
+ Elle réalise les actions suivantes :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Elle fait un dump du schéma du nœud origine, y compris les
+ informations du schéma du cluster &slony1;.
+ </para>
+
+ <para>
+ Notons que les variables d'environnement <envar>PGPORT</envar> et
+ <envar>PGHOST</envar> fournissent des informations additionnelles sur
+ l'emplacement de la base de données.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Ces informations sont chargées dans une table temporaire fraîchement
+ créée : <envar>temppayroll</envar>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Les OID de table et de séquence dans les tables &slony1; sont corrigées
+ pour pointer vers la configuration de la base temporaire.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Un script slonik est lancé pour effectuer l'action <xref
+ linkend="stmtuninstallnode"/> sur la base temporaire. Ceci élimine toutes
+ les tables et le schéma spécifique à &slony1;, et supprime les triggers
+ &slony1; des tables répliquées.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Enfin, la commande <application>pg_dump</application> est lancée sur la
+ base temporaire, et produit une copie nettoyée du schéma sur la sortie
+ standard.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2>
+<title>slony-cluster-analysis</title>
+<indexterm><primary>script - slony-cluster-analysis</primary></indexterm>
+
+<para>
+ Si vous exploitez beaucoup de bases répliquées, au sein de plusieurs clusters
+ &slony1;, il peut devenir pénible de suivre et de documenter votre
+ architecture. L'outil suivant peut vous y aider.
+</para>
+
+<para>
+ <application>slony-cluster-analysis.sh</application> est un script shell
+ conçu pour fournir une analyse à long terme de la configuration d'un cluster
+ &slony1;. Vous passez les variables d'environnement
+ <application>libpq</application> habituelles (<envar>PGHOST</envar>,
+ <envar>PGPORT</envar>, <envar>PGDATABASE</envar> et ainsi de suite) pour se
+ connecter à un membre du cluster &slony1;, et passer le nom du cluster comme
+ argument.
+</para>
+
+<para>
+ Le script effectue alors les actions suivantes :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Lancement d'une séries de requêtes sur les tables &slony1; pour obtenir
+ la liste des nœuds, des voies de communication, des ensembles de
+ réplication et des tables.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Ces données sont stockées dans un fichier temporaire situé dans
+ <filename>/tmp</filename>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Une comparaison est effectuée entre la configuration présente et la
+ configuration trouvée lors de la dernière exécution du script. Si la
+ configuration a changé, un courriel contenant les différences (produit
+ avec <application>diff</application>) est envoyée à l'adresse spécifiée.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si la configuration a changé, l'ancien fichier de configuration est
+ renommé pour indiquer quand le script a remarqué le changement.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Finalement, la configuration courante est stockée dans le dossier
+ <envar>LOGDIR</envar> dans un fichier nommé
+ <filename>cluster.last</filename>.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Il existe un exemple de script <quote>d'encapsulation</quote>,
+ <filename>slony-cluster-analysis-mass.sh</filename>, qui permet de pointer
+ vers un ensemble de clusters &slony1;.
+</para>
+
+<para>
+ Ceci devrait simplifier la taches des administrateurs ("DBA") sur deux
+ plans :
+</para>
+
+<itemizedlist>
+
+ <listitem>
+ <para>la documentation de l'état courant du système </para>
+ </listitem>
+
+ <listitem>
+ <para>la surveillance des changements de configuration.</para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2 id="configurereplication">
+<title>Génération de scripts slonik avec <filename>configure-replication.sh</filename></title>
+<indexterm><primary>générer des scripts slonik pour un cluster</primary></indexterm>
+
+<para>
+ Le script <filename>configure-replication.sh</filename>, situé dans le
+ répertoire <filename>outil</filename>, est conçu pour automatiser la
+ génération de scripts slonik de configuration de la réplication. La
+ configuration de ce script reprend la même approche que le <xref
+ linkend="testbed"/>.
+</para>
+
+<para>
+ Ce script utilise beaucoup (peut-être énormément, si votre configuration est
+ particulièrement complexe) de variables d'environnement pour déterminer la
+ forme de la configuration du cluster. Il utilise massivement les valeurs par
+ défaut et, dans la plupart des cas, peu de valeurs doivent être positionnées
+ afin d'obtenir une configuration viable.
+</para>
+
+<sect3>
+<title>Valeurs globales</title>
+
+<para>
+ Certaines valeurs sont utilisées universellement partout sur le cluster :
+</para>
+
+<variablelist>
+ <varlistentry>
+ <term><envar>CLUSTER</envar></term>
+ <listitem><para>Nom du cluster Slony-I</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>NUMNODES</envar></term>
+ <listitem><para>Nombre de nœuds à configurer</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>PGUSER</envar></term>
+ <listitem><para>Nom du super-utilisateur qui contrôle la réplication</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>PGPORT</envar></term>
+ <listitem><para>Numéro du port par défaut</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>PGDATABASE</envar></term>
+ <listitem><para>Nom de la base de données par défaut</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>TABLES</envar></term>
+ <listitem>
+ <para>
+ Liste de noms complets de tables (<emphasis>par exemple</emphasis> - un
+ nom incluant le schéma tel que <command>public.ma_table</command>)
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>SEQUENCES</envar></term>
+ <listitem>
+ <para>
+ Liste de noms complets de séquences (<emphasis>par exemple</emphasis>
+ - un nom incluant le schéma tel que <command>public.ma_sequence</command>)
+ </para>
+ </listitem>
+ </varlistentry>
+</variablelist>
+
+<para>
+ Des valeurs par défauts sont fournies pour <emphasis>chacune</emphasis> de
+ ces valeurs, si bien que si vous lancez <filename>configure-replication.sh</filename>
+ sans configurer aucune variable d'environnement, vous obtiendrez un ensemble
+ de scripts slonik. Bien sûr, ils ne correspondront pas aux bases que vous
+ voudrez configurer...
+</para>
+
+</sect3>
+
+<sect3>
+<title>Valeur spécifique à un nœud</title>
+
+<para>
+ Pour chaque nœ, il y a également quatre variables d'environnement ;
+ pour le nœud 1 :
+</para>
+
+<variablelist>
+ <varlistentry>
+ <term><envar>DB1</envar></term>
+ <listitem><para>La base de données à laquelle les scripts doivent se connecter</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>USER1</envar></term>
+ <listitem><para>Le super-utilisateur utilisé pour la connexion</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>PORT1</envar></term>
+ <listitem><para> Le port</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>HOST1</envar></term>
+ <listitem><para>L'hôte</para></listitem>
+ </varlistentry>
+</variablelist>
+
+<para>
+ Il est très probable que <envar>DB*</envar>, <envar>USER*</envar> et
+ <envar>PORT*</envar> correspondent aux variables globales
+ <envar>PGDATABASE</envar>, <envar>PGUSER</envar> et
+ <envar>PGPORT</envar> décrites précédemment ; conserver cette
+ correspondance est souvent une bonne chose.
+</para>
+
+<para>
+ En revanche, les valeurs <envar>HOST*</envar> doivent être définies
+ explicitement pour <envar>HOST1</envar>, <envar>HOST2</envar>, ...
+ car il n'est pas très malin de mettre en place un système de réplication
+ si toutes les bases redondantes se trouvent sur le même serveur !
+</para>
+
+</sect3>
+
+<sect3>
+<title>Les scripts slonik générés</title>
+
+<para>
+ Les scripts de configuration slonik sont générés dans un répertoire temporaire
+ à l'intérieur de <filename>/tmp</filename>. Leur usage est le suivant :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <filename>preamble.slonik</filename> est un fichier <quote>préambule</quote>
+ contenant les informations de connexion utilisées par les autres scripts.
+ </para>
+
+ <para>
+ Vérifier attentivement celui-ci ; vous pourrez le réutiliser pour
+ les futures opérations de maintenance que vous effectuerez sur le cluster.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>create_set.slonik</filename>
+ </para>
+
+ <para>
+ Ce script est le premier qu'il faut lancer ; il configure les
+ nœuds spécifiés en nœud &slony1;, en y ajoutant les tables
+ et les autres objets spécifiques de &slony1;.
+ </para>
+
+ <para>
+ Vous pouvez/devez lancer les processus slon juste après cette étape.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>store_paths.slonik</filename>
+ </para>
+
+ <para>
+ Le second script à exécuter ; il indique comment les &lslon;
+ doivent communiquer entre eux. Ce script suppose que tous les &lslon;
+ peuvent parler à tous les nœuds, ce qui n'est peut-être pas exact
+ dans un environnement peuplé de pare-feu complexes. Si cette supposition
+ n'est pas correcte, vous devez modifier ce script pour corriger les voies
+ de communications.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>create_set.slonik</filename>
+ </para>
+
+ <para>
+ Ce script configure l'ensemble de réplication composé de toutes les
+ tables et les séquences présentes dans le schéma de la base de données
+ de votre application.
+ </para>
+
+ <para>
+ Lorsque vous lancez ce script, la seule action menée est l'ajout de
+ triggers sur le nœud origine (nœud #1) qui vont commencer
+ à collecter les mises à jours. La réplication ne commencera qu'à l'étape
+ #5...
+ </para>
+
+ <para>
+ Il y a deux suppositions dans ce scripts qui peuvent ne pas être valides
+ dans certaines circonstances :
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ que toutes les tables et les séquences soit répliquées
+ </para>
+
+ <para>
+ Ceci n'est pas valide lorsque de nouvelles tables sont ajoutée dans
+ votre schéma et qu'elles ne sont pas ajoutées dans la liste
+ <envar>TABLES</envar>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ que toutes les tables sont définies avec des clefs primaires
+ </para>
+
+ <para>
+ La bonne pratique est de toujours créer et utiliser de vraies clefs
+ primaires. Si vous avez des tables qui nécessitent de choisir une
+ clef primaire candidate ou qui nécessite la création d'une clef
+ additionnelle avec la commande <xref linkend="stmttableaddkey"/>,
+ vous devez modifier ce script à la main pour l'accommoder.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>subscribe_set_2.slonik</filename>
+ </para>
+
+ <para>
+ et 3, 4, 5, si vous configurez d'autres nœuds...
+ </para>
+
+ <para>
+ Ceci est l'étape qui <quote>déclenche</quote> la réplication.
+ </para>
+
+ <para>
+ Ce script fait la supposition que tous les nœuds abonnés voudront
+ s'abonner directement au nœud origine. Si vous souhaitez mettre en
+ place des <quote>sous-clusters</quote> avec peut-être un nœud
+ maître dans chaque centre de données, vous devez modifier ces scripts.
+ </para>
+
+ <para>
+ Les processus slon doivent fonctionner au moment où vous réalisez cette
+ étape. Il est absurde de lancer ces scripts lorsque ce n'est pas le cas.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect3>
+
+</sect2>
+
+<sect2 id="bsd-ports-profile">
+<title><filename>slon.in-profiles</filename></title>
+<subtitle>profiles dans le style d'Apache pour FreeBSD <filename>ports/databases/slony/*</filename></subtitle>
+
+<para>
+ Dans le répertoire <filename>tools</filename>, le script
+ <filename>slon.in-profiles</filename> permet de lancer des instances &lslon;
+ lors du démarrage du système. Il est conçu pour interagir avec le système des
+ ports de FreeBSD.
+</para>
+
+</sect2>
+
+</sect1>
Deleted: traduc/tags/slony_1_2_12/bestpractices.xml
===================================================================
--- traduc/trunk/slony/bestpractices.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/bestpractices.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,929 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="bestpractices">
-<title><quote>Bonnes Pratiques</quote> avec &slony1;</title>
-<indexterm><primary>bonnes pratiques pour utiliser &slony1;</primary></indexterm>
-
-<para>
- Il est courant pour les administrateurs de vouloir exploiter des systèmes en
- utilisant un ensemble de <quote>bonnes pratiques</quote> disponibles et
- documentées. Documenter ce genre de choses est essentiel pour l'ISO 9000,
- l'ISO 9001 et d'autres type de certifications d'organisation.
-</para>
-
-<para>
- Il est intéressant d'introduire toute discussion sur des <quote>bonnes
- pratiques</quote> en mentionnant que chaque organisation utilisant &slony1;
- est unique et qu'il est nécessaire qu'une politique locale reflète les
- caractéristiques administratives locales. C'est pour cette raison que
- &slony1; n'impose <emphasis>pas</emphasis> ses propres règles pour des
- points tels que les <link linkend="failover">bascules d'urgence</link> ;
- elles devront être déterminées en fonction de l'architecture globale de
- votre réseau, de votre ensemble de serveurs de base de données et de votre
- manière d'utiliser ces serveurs.
-</para>
-
-<para>
- Il y a, toutefois, un certain nombre de découvertes des pionniers de &slony1;
- qui peuvent au moins aider à concevoir le genre de règles d'administration
- que vous pourriez mettre en place.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- &slony1; est un système multi-clients et multi-serveurs complexe, ce qui
- implique qu'il existe un ensemble presque infini d'endroits où des
- problèmes peuvent surgir.
- </para>
-
- <para>
- C'est donc naturellement que la maintenance d'un environnement propre,
- cohérent est réellement décisif car tout type de
- <quote>cafouillage</quote> dans l'environnement peut provoquer des
- problèmes ou masquer le problème réel.
- </para>
-
- <para>
- De nombreux utilisateurs ont rapporté des problèmes provenants
- d'incompatibilités entre les versions de &slony1;, les bibliothèques
- locales et les bibliothèques de &postgres;. Chaque détail compte :
- vous devez identifier clairement sur quels hôtes sont hébergées quelles
- versions de quels logiciels.
- </para>
-
- <para>
- Normalement il s'agit juste d'être discipliné lors du déploiement de vos
- logiciels, et ce défi est une conséquence naturelle lorsqu'on met en
- place un système distribué constitué par un grand nombre de composants
- qui doivent correspondre.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si un script slonik ne fonctionne pas comme prévu à la première
- tentative, il serait téméraire de tenter de l'exécuter à nouveau tant
- que le problème n'a pas été trouvé et résolu.
- </para>
-
- <para>
- Il y a très peu de commandes slonik tel que <xref
- linkend="stmtstorepath"/> qui se comporte de manière déterministe ;
- si vous exécutez <xref linkend="stmtstorepath"/> plusieurs fois,
- cela mettra plusieurs fois la même valeur dans la table
- <envar>sl_path</envar>.
- </para>
-
- <para>
- Au contraire, <xref linkend="stmtsubscribeset"/> se comporte de deux
- manières <emphasis>très</emphasis> différentes selon que l'abonnement
- a déjà été activé ou pas ; si l'initialisation de l'abonnement n'a
- pas fonctionné à la toute première tentative, soumettre à nouveau cette
- requête n'arrangera <emphasis>pas</emphasis> la situation.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Principe : utilisez un fuseau horaire stable et non-ambigüe tel que
- UTC ou GMT.
- </para>
-
- <para>
- Les utilisateurs ont rencontrés des problèmes pour faire fonctionner
- &lslon; correctement lorsque leur système utilisait un fuseau horaire
- que &postgres; ne pouvait pas reconnaître tel que CUT0 ou WST. Il est
- nécessaire que vous utilisiez un fuseau horaire que &postgres; reconnaît
- correctement. De plus, il est préférable d'utiliser un fuseau qui n'est
- pas soumis au basculement entre heure d'été et heure d'hiver.
- </para>
-
- <para>
- Le choix <quote>géographiquement neutre</quote> semble être
- <command><envar>TZ</envar>=UTC</command> ou
- <command><envar>TZ</envar>=GMT</command>. Par ailleurs, assurez-vous que
- vos serveurs sont <quote>synchronisés</quote> grâce à l'utilisation
- de NTP sur l'ensemble de votre environnement.
- </para>
-
- <para>
- Voir aussi <xref linkend="times"/>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Principe : les transactions longues, c'est mal.
- </para>
-
- <para>
- La FAQ a un chapitre sur la <link linkend="pglistenerfull">croissance de
- &pglistener;</link> qui explique tout cela en détails ; pour
- simplifier, les transactions longues ont de nombreux effets secondaires.
- Elles sont problématiques en particulier sur un nœud
- <quote>origine</quote> s'accaparant les verrous, rendant inefficace les
- VACUUM, et ainsi de suite.
- </para>
-
- <para>
- Dans la version 1.2, certains comportements <quote>désagréables</quote>
- devraient être diminués car :
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- Les événements dans &pglistener; sont seulement générés lorsque
- les mise à jours de réplication sont relativement rare, ce qui devrait
- impliquer que les systèmes chargés ne vont pas générer beaucoup de
- lignes mortes dans cette table.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Le système va périodiquement faire un troncage (en utilisant
- <command>TRUNCATE</command> pour nettoyer l'ancienne table) entre les
- deux tables de logs, <xref linkend="table.sl-log-1"/> et <xref
- linkend="table.sl-log-2"/>, évitant une croissance illimitée de
- l'espace <quote>mort</quote> à cet endroit.
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- Les règles de <link linkend="failover">bascule en urgence</link>
- devraient être planifiées à l'avance.
- </para>
-
- <para>
- Cela peut simplement se résumer à réfléchir à une liste de priorités
- indiquant qui devrait basculer vers quoi, plutôt que d'essayer
- d'automatiser la bascule. Quoiqu'il en soit, savoir au préalable ce
- qu'il faut faire réduit le nombre d'erreurs commises.
- </para>
-
- <para>
- Chez Afilias, une grande variété de guides internes, tel que <citation>Le
- guide de l'administrateur réveillé à 3 heures du matin...</citation>, ont
- été rédigé pour fournir les procédures à suivre en cas d'événements
- <quote>malheureux</quote>. Ce genre de matériel est hautement spécifique
- à l'environnement et à l'ensemble d'applications présentes, donc vous
- devriez rédiger vos propres documents. Ceci est un des composants vitaux
- de tout procédure de reprise après crash.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <xref linkend="stmtmoveset"/> doit être utlisé pour la maintenance
- préventive afin d'éviter l'apparition des problèmes nécessitant une
- <link linkend="failover">bascule après panne (« failover »)</link>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- La politique de <command>VACUUM</command> doit être définie avec soin.
- </para>
-
- <para>
- Comme indiqué précédemment, <quote>les transactions longues sont
- maléfiques</quote>. La commande <command>VACUUM</command> n'est pas
- une exception à cette règle. Un <command>VACUUM</command> sur une grande
- table ouvrira une transaction longue qui aura tous les effets négatifs
- déjà cités.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si vous utilisez le processus autovacuum avec une version récente de
- &postgres;, vous pouvez éviter de le faire pour les tables &slony1; car
- &slony1; est un peu plus intelligent que le démon autovaccuum lorsqu'il
- s'agit des VACUUM dans des conditions de réplication (<emphasis>par
- exemple</emphasis> : la purge des anciennes données).
- </para>
-
- <para>
- Reportez-vous au chapitre <xref linkend="maintenance-autovac"/> pour plus
- de détails.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Il a été prouvé qu'il est préférable d'exécuter tous les démons &lslon;
- sur un serveur central pour chaque sous-réseau.
- </para>
-
- <para>
- Chaque &lslon; doit être hébergé par hôte sur le même réseau local que
- le nœud qu'il opère car il envoie <emphasis>beaucoup</emphasis>
- de communications avec sa base de donnée et que la connexion doit être
- aussi fiable que possible.
- </para>
-
- <para>
- En théorie, les <quote>meilleures</quote> performances sont prévues
- lorsque l&lslon; fonctionne sur le même serveur que la base qu'il opère.
- </para>
-
- <para>
- En pratique, déployer les processus &lslon; et leur configuration à
- travers un réseau d'une douzaine de serveurs se révèle être
- difficilement gérable.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Les processus &lslon; doivent évoluer dans le même <quote>contexte
- réseau</quote> que le nœud d'origine, afin que la liaison entre
- eux soit une connexion <quote>locale</quote>. N'établissez
- <emphasis>pas</emphasis> ce genre de liaison à travers un réseau WAN.
- </para>
-
- <para>
- Une coupure de lien WAN peut provoquer des connexions
- <quote>zombies</quote>, et le comportement typique du TCP/IP consiste à
- <link linkend="multipleslonconnections">laisser ces connexions persister,
- empêchant le démon slon de redémarrer pendant environ deux heures</link>.
- </para>
-
- <para>
- Il n'est pas difficile de remédier à cela. Vous devez simplement tuer les
- processus liés aux connexions persistantes avec la commande <command>kill
- SIGINT</command>. Cependant en exécutant les &lslon; localement, vous
- êtes généralement à l'abri de ce genre de problèmes.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si vous rencontrez ce genre de problèmes, avant de vous exciter, essayez
- de tuer et redémarrer tous les processus &lslon;. Historiquement, cette
- méthode a souvent résolu ce genre de <quote>petit tracas.</quote>.
- </para>
-
- <para>
- À quelques rares exceptions, il n'est pas très grave de tuer et relancer
- les processus &lslon;. Chaque &lslon; se connecte à la base de données
- qu'il gère, puis ouvre les connexions nécessaires à la propagation des
- événements. Si vous tuez un &lslon;, vous provoquez simplement
- l'interruption de ces connexions. Si un évènement <command>SYNC</command>
- ou un autre événement est en cours de propagation, il n'y a pas de
- problème : la transaction sera annulée (via un ROLLBACK) et lorsque
- le &lslon; sera relancé, l'évènement sera retraité à partir de zéro.
- </para>
-
- <para>
- L'exception qui rend un redémarrage de &lslon; indésirable est le cas où
- une commande <command>COPY_SET</command> est en cours d'exécution sur un
- grand ensemble de réplication. Dans ce genre de cas, arrêter un &lslon;
- peut annuler plusieurs heures de travail.
- </para>
-
- <para>
- Dans les premières versions de &slony1;, il était fréquent que des
- connexions soient un peu <quote>dérangées</quote>, ce qu'on pouvait
- réparer en redémarrant &lslon;. Ceci est devenu nettement plus rare mais
- il est parfois utile de redémarrer &lslon;. En cas de <quote>panne
- réseau</quote>, cela peut résoudre le problème des connexions défuntes.
- </para>
- </listitem>
-
- <listitem>
- <para>
- La section sur les <link linkend="ddlchanges">changements de modèle de
- données</link> détaille quelques bonnes pratiques qui sont utiles
- lorsqu'on souhaite modifier le schéma de la base de données.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Gestion des clefs primaires.
- </para>
-
- <para>
- Comme précisé dans la section <link linkend="definingsets">Ensembles de
- réplication</link>, il est <emphasis>idéal</emphasis> que chaque table
- répliquée dispose d'une vraie contrainte de clef primaire ; il est
- <emphasis>acceptable</emphasis> d'utiliser une <quote>clef primaire
- candidate</quote>.
- </para>
-
- <para>
- Il n'est <emphasis>pas recommandé</emphasis> d'utiliser une clef définie
- par &slony1; (créée par <xref linkend="stmttableaddkey"/>) pour proposer
- une clef primaire candidate car cela introduit la possibilité d'échecs de
- certaines mises à jour sur la table à cause de l'index unique de cette
- clef. Ceci entraînerait potentiellement des bogues dans votre application
- à cause de &slony1;.
- </para>
-
- <warning>
- <para>
- Dans la version 2 de &slony1;, <xref linkend="stmttableaddkey"/> n'est
- plus supportée. Vous <emphasis>devez</emphasis> absolument avoir soit
- une vraie clef primaire, soit une clef primaire candidate.
- </para>
- </warning>
- </listitem>
-
- <listitem>
- <para>
- La section <link linkend="definesets">Définir les ensembles de
- réplication</link> vous suggère des stratégies pour déterminer comment
- regrouper les tables et les séquences en ensembles de réplication.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Il est évident que les actions qui peuvent supprimer beaucoup de données
- doivent être effectuées avec le plus grand soin. La section <link
- linkend="dropthings">Supprimer des éléments de la réplication</link>
- évoque les différentes sortes de <quote>suppression</quote> que &slony1;
- supporte.
- </para>
- </listitem>
-
- <listitem>
- <para><link linkend="locking">Problèmes d'inter-blocages</link></para>
-
- <para>
- Certaines opérations &slony1;, notament <link
- linkend="stmtsetaddtable"><command>set add table</command></link>,
- <link linkend="stmtmoveset"><command> move set</command></link>,
- <link linkend="stmtlockset"><command> lock set </command></link>
- et <link linkend="stmtddlscript"><command>execute script</command></link>
- nécessitent l'acquisition de <emphasis>verrous exclusifs</emphasis> sur
- les tables répliquées.
- </para>
-
- <para>
- En fonction de type d'activité de votre base de données, cela peut (ou
- pas) provoquer des coupures de services (heureusement assez brèves).
- </para>
- </listitem>
-
- <listitem>
- <para>Que faire des ordres DDL ?</para>
-
- <para>
- &slony1; fonctionne en détectant les mises à jour sur les tables grâce à
- des triggers qui sont placés sur ces tables. Cela implique que les mises
- à jours que se font au moyen de méthodes qui ne déclenchent pas les
- triggers ne seront pas propagées. Les commandes <command>ALTER
- TABLE</command>, <command>CREATE OR REPLACE FUNCTION</command>,
- <command>CREATE TABLE</command> sont toutes des requêtes SQL que &slony1;
- ne peut pas détecter.
- </para>
-
- <para>
- Pour ce genre de situation, la philosophie de &slony1; consiste à
- considérer que les développeurs compétents n'écrivent jamais de code
- auto-modifiant et en particulier du code modifiant les modèles de
- données à la volée. &slony1; ne cherche pas à faciliter ce genre de
- modification du schéma de données.
- </para>
-
- <para>
- Cependant, il existe des cas où cela est nécessaire, ainsi <link
- linkend="stmtddlscript"><command>execute script</command> est fournie
- pour appliquer des changements DDL au même point dans le flux de
- transactions sur tous les serveurs</link>.
- </para>
-
- <para>
- Malheureusement, cela provoque de nombreux verrous sur les objets de
- la base de données. Modifier les tables nécessite l'acquisition d'un
- verrou exclusif sur ces objets ; ainsi le <command>script
- d'exécution des modifications</command> entraîne un verrou exclusif sur
- <emphasis>toutes</emphasis> les tables répliquées. Cela peut s'avérer
- très problématique lorsque les applications fonctionnent ; des
- inter-blocages (« deadlocks ») peuvent alors se produire.
- </para>
-
- <para>
- Une position particulièrement dogmatique défendue par certains consiste à
- dire qu'il faut <emphasis>toujours</emphasis> propager les changements de
- modèles de données avec un <command>script d'exécution</command>. Cela
- garantit que les nœuds restent cohérents. Cependant, le coût des
- verrous et des inter-blocages est trop élevé pour certains utilisateurs.
- </para>
-
- <para>
- Chez Afilias, notre approche est moins dogmatique ; il y a
- <emphasis>certains</emphasis> changements qui <emphasis>doivent</emphasis>
- être appliqués avec un <command>script d'exécution</command> mais nous
- appliquons certaines modifications de manière indépendante.
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- Liste de changements qui doivent être effectuée dans un
- <command>script d'exécution</command> :
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- Toutes les commandes <command>ALTER TABLE</command>.
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- Listes des changement qui ne nécessitent pas un <command>script
- d'exécution</command> :
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- <command>CREATE INDEX</command>
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>CREATE TABLE</command>
- </para>
-
- <para>
- Les tables qui ne sont pas répliquées n'ont pas besoin de ces
- mécanismes.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>CREATE OR REPLACE FUNCTION</command>
- </para>
-
- <para>
- Typiquement, le chargement de nouvelles version de fonctions peut
- être effectuée sans que &slony1; en soit <quote>averti</quote>. À
- l'exception évidente des cas où la nouvelle fonction est déployée
- suite à la modification d'une table. Dans ce cas-là, la nouvelle
- version doit être déployée de manière synchronisée avec le
- <command>script d'exécution</command> qui modifie la table.
- </para>
-
- <para>
- De la même manière, les ordres <command>CREATE TYPE</command>,
- <command>CREATE AGGREGATE</command>, etc. n'ont pas besoin
- d'être forcément insérés de manière <quote>parfaitement
- synchronisés</quote> sur l'ensemble des nœuds.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Les ordres de gestion des autorisations, tels que <command>CREATE
- USER</command>, <command> CREATE ROLE </command>,
- <command>GRANT</command>, etc. sont inutiles pour &slony1; car
- ce dernier est exécuté avec les droits de
- <quote>super-utilisateur</quote>.
- </para>
-
- <para>
- Dans la pratique, il est utile d'avoir différentes politiques de
- sécurité sur les nœuds. L'accès au nœud
- <quote>maître</quote> doit être limité aux applications qui en
- ont réellement besoin. Les utilisateurs effectuant de l'extraction
- de données (« reporting ») ont généralement des droits
- plus limités sur le nœud maître que sur les nœuds
- abonnés.
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem id="slonyuser">
- <para>
- Noms d'utilisateur spécifiques à &slony1;.
- </para>
-
- <para>
- Il s'est avéré utile de définir un utilisateur <command>slony</command>
- employé uniquement par &slony1;, un utilisateur distinct de l'utilisateur
- générique <command>postgres</command> ou <command>pgsql</command>.
- </para>
-
- <para>
- Lorsque toutes sortes d'activités de <quote>maintenance</quote>
- automatiques, telles que les <command>VACUUM</command> et les sauvegardes,
- sont effectuées avec l'<quote>identité</quote> de l'utilisateur &postgres;,
- cela peut assez facilement provoquer des problèmes d'inter-blocages
- (« deadlocks »).
- </para>
-
- <para>
- Par exemple, une série de <command>VACUUM</command> qui sont lancés de
- manière inattendue sur une base de donnée avec un gros événement
- <command>SUBSCRIBE_SET</command> en cours d'exécution peut entraîner des
- inter-blocages qui peuvent annuler plusieurs heures de travail de copie
- de données.
- </para>
-
- <para>
- À l'inverse, si les différentes opérations de maintenance sont exécutées
- par différents utilisateurs, vous pourrez assurer la réussite d'une
- opération vitale telle que <command>SUBSCRIBE_SET</command>, en bloquant
- les autres utilisateurs au niveau du fichier
- <filename>pg_hba.conf</filename>, et en autorisant uniquement
- l'utilisateur slony, ce qui réduit considérablement les risques lors
- d'une souscription.
- </para>
- </listitem>
-
- <listitem>
- <para>Configuration des chemins</para>
-
- <para>
- La section sur les <link linkend="plainpaths">voies de
- communications</link> évoque les problèmes liés aux connexions réseau
- nécessaires au bon fonctionnement de &slony1;.
- </para>
- </listitem>
-
- <listitem>
- <para>Réduction des super-pouvoirs</para>
-
- <para>
- Traditionellement, on considère que <quote>&slony1; a besoin de
- connexions en mode super-utilisateur</quote>. Cela n'est pas totalement
- vrai et si l'usage excessif de comptes super-utilisateurs pose problème,
- il est possible de réduire nettement cet usage.
- </para>
-
- <para>
- Il est vrai que chaque &lslon; <emphasis>doit</emphasis> avoir une
- connexion super-utilisateur afin de gérer le nœud qu'il opère.
- Il doit pouvoir modifier le catalogue système afin de mettre en place les
- abonnements et procéder aux modifications (<emphasis>par exemple</emphasis>
- pour exécuter <xref linkend="stmtddlscript"/> et d'autres évènement qui
- peuvent modifier le rôle d'une tables répliqué sur un nœud local).
- </para>
-
- <para>
- Toutefois, les connexions que les processus &lslon; ouvrent vers d'autres
- nœuds afin d'accéder aux événements et aux souscriptions n'ont pas
- besoin d'avoir d'autant de droits. Ainsi, on peut mettre en place un
- <quote>utilisateur faible</quote> assigné à toutes les requêtes <xref
- linkend="stmtstorepath"/>. Les droits minimaux de cet utilisateur,
- appellons-le <command>weakuser</command>, sont les suivantes :
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- Il doit avoir accès en lecture sur le schéma spécifique de &slony1; ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- Il doit avoir accès en lecture sur toutes les tables et les séquences
- de ce schéma ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- Il doit avoir accès en écriture sur la table <envar>sl_nodelock</envar>
- et la séquence <envar>sl_nodelock_nl_conncnt_seq</envar> ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- Lors de la souscrition, il doit avoir accès en lecture sur toutes les tables répliquées.
- </para>
-
- <para>
- Après la souscription, il n'est plus nécessaire d'accéder aux tables répliquées.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Il est parfois nécessaire de lire les tables dans pg_catalog sans
- qu'on ait pu vérifier le niveau d'accès convenable.
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- Dans la version 1.3, les tests du <xref linkend="testbed"/> permettent
- l'utilisation d'un utilisateur faible (<envar>WEAKUSER</envar>) afin de
- tester si les droits définis sont suffisants pour supporter la
- réplication.
- </para>
- </listitem>
-
- <listitem>
- <para>
- La section sur les <link linkend="listenpaths">voies d'écoute</link>
- parle des problèmes entourant la table <xref
- linkend="table.sl-listen"/>.
- </para>
-
- <para>
- À partir de la version &slony1; 1.1, le contenu de cette table était
- calculé automatiquement en se basant sur les informations dont disposait
- &slony1;, ce qui devrait supprimer les problèmes rencontrés. Beaucoup de
- problèmes de communication inexplicables, avec des nœuds qui
- n'arrivent pas à se parler alors que c'est techniquement possible,
- étaient du à une configuration incorrecte des voies d'écoutes.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Utilisez <filename>test_slony_state.pl</filename> pour rechercher les
- problèmes de configuration.
- </para>
-
- <para>
- Il s'agit d'un script Perl qui se connecte à un nœud &slony1; puis
- parcourt la configuration &slony1; à la recherche de différentes
- conditions qui indiquent la présence de problèmes, en particulier :
- </para>
-
- <itemizedlist>
- <listitem><para>le gonflement de certaines tables de congfiguration ;</para></listitem>
- <listitem><para>l'analyse des voies d'écoute ;</para></listitem>
- <listitem><para>l'analyse de la propagation et de la confirmation des événements.</para></listitem>
- </itemizedlist>
-
- <para>
- Si, de manière mystérieuse, la réplication <quote>ne marche pas</quote>,
- cet outil peut vérifier beaucoup de problèmes potentiels pour vous.
- </para>
- </listitem>
-
- <listitem>
- <para>Configurer &lslon;</para>
-
- <para>
- À partir de la version 1.1, la configuration de &lslon; peut être
- définie par ligne de commande ou dans des fichiers de configuration.
- De <quote>bonnes</quote> pratiques sont conseillées dans les deux
- cas :
- </para>
-
- <itemizedlist>
- <listitem>
- <para>Configuration via les options en ligne de commande</para>
-
- <para>
- Cette approche a le mérite de rendre visible dans l'environnement
- système toutes les options actives. Ainsi, s'il y en a beaucoup,
- cela peut devenir pénible à lire.
- </para>
-
- <para>
- Malheureusement, si vous invoquez &lslon; à partir d'une ligne de
- commande, vous pouvez <emphasis>oublier</emphasis> d'inclure la
- configuration de &logshiplink; et ainsi détruire les séquences de
- logs pour les nœuds de log shipping.
- </para>
- </listitem>
-
- <listitem>
- <para>
- À la différence des options en ligne de commande, les options
- actives ne sont <emphasis>pas</emphasis> visibles. Elles peuvent
- seulement être positionnées à partir du nom et du contenu du
- fichier de configuration de &lslon; et ne refléteront pas les
- changements apparus dans le fichier de configuration.
- </para>
-
- <para>
- En plaçant les options dans un fichier, vous n'en oublierez aucune,
- ce qui est plus sûr pour &logshiplink;.
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>Taches à faire lorsqu'on abonne un nœud</para>
-
- <para>
- Lorsqu'un nouveau nœud exécute l'événement
- <command>COPY_SET</command> sur un grand ensemble de réplication
- (<emphasis>par exemple</emphasis> un ensemble qui nécessite un
- abonnement de plusieurs heures), il est prouvé qu'il est souhaitable de
- verrouiller l'accès au nœud pour tous les utilisateurs autres que
- <command>slony</command> car :
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- Les applications s'exécutent sur des données partiellement copiées
- qui ne seront pas cohérentes.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Il est possible que certaines applications (et certains scripts de
- maintenance) soumettent une combinaison de requêtes qui placeront
- le système dans une situation d'inter-blocage
- (« deadlock »), ce qui annulera l'événement
- <command>COPY_SET</command> et impliquera le ré-abonnement complet
- du nœud.
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
-</itemizedlist>
-
-<para>
- Il <emphasis>peut</emphasis> être intéressant de désactiver la fonctionnalité
- <function>fsync</function> de &postgres; pendant la copie des données, car cela
- améliorera les performances, et en cas d'échec lors de l'évènement
- <command>COPY_SET</command>, vous pourrez redémarrer avec une copie entière de
- l'ensemble de réplication.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>Gestion de slonik</para>
-
- <para>
- Les notes sur l'<link linkend="usingslonik">utilisation de Slonik</link>
- décrivent certaines leçons apprises en gérant un grand nombre de scripts
- <xref linkend="slonik"/>.
- </para>
-
- <para>
- Voici les principes importants dégagés lors de la création de ces
- scripts :
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- Utiliser des fichiers <quote>préambule</quote> est <emphasis>hautement
- recommandé</emphasis> car cela implique que vous utilisiez et
- réutilisiez des préambules vérifiés maintes fois.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Toute opportunité de générer automatiquement la configuration soit en
- la récupérant dans une base de données, soit en utilisant un script
- de génération vous aidera à éviter les erreurs humaines.
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- Gérer un très grand ensemble de réplication.
- </para>
-
- <para>
- Certains utilisateurs ont bâti des réplications sur des ensembles de
- plusieurs dizaines, voire plusieurs centaines de gigaoctets, ce qui
- ajoute des <quote>contraintes</quote> sur le système, en particulier
- lorsqu'il faut plusieurs jours pour effectuer un évènement
- <command>COPY_SET</command>. Voici quelques principes qui ont été définis
- pour gérer ce genre de situations.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Supprimer tous les index autres que les index primaires lorsque l'évènement
- en <command>COPY_SET</command> est exécuté.
- </para>
-
- <para>
- Lorsque les données sont copiées dans une table qui dispose d'index,
- &postgres; construit les index de manière incrémentale, à la volée. Ceci
- est beaucoup plus lent que simplement copier les donnés dans une table
- puis de recréer chaque index <quote>ex nihilo</quote> car cette dernière
- opération profite de l'avantage de la mémoire de tri.
- </para>
-
- <para>
- Dans &slony1; version 1.1.5 et dans les versions ultérieures, les index
- sont supprimés et recréés automatiquement, ce qui rend caduque ce conseil.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si beaucoup de mises à jour ont lieu lorsque de grands ensembles sont
- copiés, ceci peut mener à un nombre énorme d'événements
- <command>SYNC</command> sur le nœud qui s'abonne.
- </para>
-
- <para>
- Si un <command> SYNC </command> est généré une fois par seconde, ceci
- conduit à un <quote>retard</quote> de plus de 90 000
- <command>SYNC</command> par jour, pendant probablement plusieurs jours.
- </para>
-
- <para>
- Parallèlement, on constate une croissance <emphasis>énorme</emphasis>
- des tables <xref linkend="table.sl-log-1"/> et <xref
- linkend="table.sl-seqlog"/>. Malheureusement, une fois que
- <command>COPY_SET</command> est terminé, on constate que les requêtes
- sur ces tables se font via des <command>parcours séquentiels</command>.
- Même si le <command>SYNC</command> ne traite qu'une petite partie de
- ces 90 000 événements <command>SYNC</command>, la table sera lue
- dans son ensemble. Dans de tels cas, il est possible que le nœud
- abonné ne rattrape jamais le nœud origine.
- </para>
-
- <para>
- Plusieurs taches peuvent résoudre ce problème, notamment en réglant avec
- soin les paramètres &lslon; :
- </para>
- </listitem>
-
- <listitem>
- <para>
- Assurez-vous qu'il existe sur le nœud <quote>maître</quote>
- un index sur <function>sl_log_1(log_xid)</function>. S'il n'y en a pas,
- comme avec les versions de &slony1; inférieures à la version 1.1.1,
- regardez dans le fichier <filename>slony1_base.sql</filename> pour la
- configuration correcte de cet index.
- </para>
-
- <para>
- Dans les versions 1.2 et suivantes, il y a un processus qui ajoute
- automatiquement les index partiels par numéro de nœud d'origine,
- ce qui est la forme optimale pour ces index.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Sur un nœud abonné, ajoutez le nombre d'évènements
- <command>SYNC</command> traités ensemble, en réglant le paramètre
- <xref linkend= "slon-config-sync-group-maxsize"/> à une valeur lui
- permettant une portion significative de la masse d'événements
- <command>SYNC</command>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Sur le nœud abonné, réglez le paramètre <xref
- linkend="slon-config-desired-sync-time"/> à 0 car le système de
- regroupement adaptatif des <command>SYNC</command> fonctionne avec de
- petits groupes qui, sous certaines circonstances, donne de mauvaises
- performances.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Augmenter le <xref linkend="slon-config-sync-interval"/> sur le
- nœud origine <xref linkend="slon"/> afin que les événements
- <command>SYNC</command> soient générés moins fréquemment. Si un
- <command>SYNC</command> est simplement généré une fois par minute plutôt
- qu'une fois par seconde, cela divisera par soixante le nombre
- d'évènements.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Il faudra probablement utiliser le <xref linkend="slon-config-vac-frequency"/>
- pour désactiver les VACUUM lancés par <xref linkend="slon"/> afin
- d'utiliser vos propres scripts de VACUUM car il y aura une masse de
- données non purgeables pendant que les données seront copiées et que
- l'abonné commencera à rattraper le fournisseur.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/bestpractices.xml (from rev 1244, traduc/trunk/slony/bestpractices.xml)
===================================================================
--- traduc/tags/slony_1_2_12/bestpractices.xml (rev 0)
+++ traduc/tags/slony_1_2_12/bestpractices.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,906 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="bestpractices">
+<title><quote>Bonnes Pratiques</quote> avec &slony1;</title>
+<indexterm><primary>bonnes pratiques pour utiliser &slony1;</primary></indexterm>
+
+<para>
+ Il est courant pour les administrateurs de vouloir exploiter des systèmes en
+ utilisant un ensemble de <quote>bonnes pratiques</quote> disponibles et
+ documentées. Documenter ce genre de choses est essentiel pour l'ISO 9000,
+ l'ISO 9001 et d'autres type de certifications d'organisation.
+</para>
+
+<para>
+ Il est intéressant d'introduire toute discussion sur des <quote>bonnes
+ pratiques</quote> en mentionnant que chaque organisation utilisant &slony1;
+ est unique et qu'il est nécessaire qu'une politique locale reflète les
+ caractéristiques administratives locales. C'est pour cette raison que
+ &slony1; n'impose <emphasis>pas</emphasis> ses propres règles pour des
+ points tels que les <link linkend="failover">bascules d'urgence</link> ;
+ elles devront être déterminées en fonction de l'architecture globale de
+ votre réseau, de votre ensemble de serveurs de base de données et de votre
+ manière d'utiliser ces serveurs.
+</para>
+
+<para>
+ Il y a, toutefois, un certain nombre de découvertes des pionniers de &slony1;
+ qui peuvent au moins aider à concevoir le genre de règles d'administration
+ que vous pourriez mettre en place.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ &slony1; est un système multi-clients et multi-serveurs complexe, ce qui
+ implique qu'il existe un ensemble presque infini d'endroits où des
+ problèmes peuvent surgir.
+ </para>
+
+ <para>
+ C'est donc naturellement que la maintenance d'un environnement propre,
+ cohérent est réellement décisif car tout type de
+ <quote>cafouillage</quote> dans l'environnement peut provoquer des
+ problèmes ou masquer le problème réel.
+ </para>
+
+ <para>
+ De nombreux utilisateurs ont rapporté des problèmes provenants
+ d'incompatibilités entre les versions de &slony1;, les bibliothèques
+ locales et les bibliothèques de &postgres;. Chaque détail compte :
+ vous devez identifier clairement sur quels hôtes sont hébergées quelles
+ versions de quels logiciels.
+ </para>
+
+ <para>
+ Normalement il s'agit juste d'être discipliné lors du déploiement de vos
+ logiciels, et ce défi est une conséquence naturelle lorsqu'on met en
+ place un système distribué constitué par un grand nombre de composants
+ qui doivent correspondre.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si un script slonik ne fonctionne pas comme prévu à la première
+ tentative, il serait téméraire de tenter de l'exécuter à nouveau tant
+ que le problème n'a pas été trouvé et résolu.
+ </para>
+
+ <para>
+ Il y a très peu de commandes slonik tel que <xref
+ linkend="stmtstorepath"/> qui se comporte de manière déterministe ;
+ si vous exécutez <xref linkend="stmtstorepath"/> plusieurs fois,
+ cela mettra plusieurs fois la même valeur dans la table
+ <envar>sl_path</envar>.
+ </para>
+
+ <para>
+ Au contraire, <xref linkend="stmtsubscribeset"/> se comporte de deux
+ manières <emphasis>très</emphasis> différentes selon que l'abonnement
+ a déjà été activé ou pas ; si l'initialisation de l'abonnement n'a
+ pas fonctionné à la toute première tentative, soumettre à nouveau cette
+ requête n'arrangera <emphasis>pas</emphasis> la situation.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Principe : utilisez un fuseau horaire stable et non-ambigüe tel que
+ UTC ou GMT.
+ </para>
+
+ <para>
+ Les utilisateurs ont rencontrés des problèmes pour faire fonctionner
+ &lslon; correctement lorsque leur système utilisait un fuseau horaire
+ que &postgres; ne pouvait pas reconnaître tel que CUT0 ou WST. Il est
+ nécessaire que vous utilisiez un fuseau horaire que &postgres; reconnaît
+ correctement. De plus, il est préférable d'utiliser un fuseau qui n'est
+ pas soumis au basculement entre heure d'été et heure d'hiver.
+ </para>
+
+ <para>
+ Le choix <quote>géographiquement neutre</quote> semble être
+ <command><envar>TZ</envar>=UTC</command> ou
+ <command><envar>TZ</envar>=GMT</command>. Par ailleurs, assurez-vous que
+ vos serveurs sont <quote>synchronisés</quote> grâce à l'utilisation
+ de NTP sur l'ensemble de votre environnement.
+ </para>
+
+ <para>
+ Voir aussi <xref linkend="times"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Principe : les transactions longues, c'est mal.
+ </para>
+
+ <para>
+ La FAQ a un chapitre sur la <link linkend="pglistenerfull">croissance de
+ &pglistener;</link> qui explique tout cela en détails ; pour
+ simplifier, les transactions longues ont de nombreux effets secondaires.
+ Elles sont problématiques en particulier sur un nœud
+ <quote>origine</quote> s'accaparant les verrous, rendant inefficace les
+ VACUUM, et ainsi de suite.
+ </para>
+
+ <para>
+ Dans la version 1.2, certains comportements <quote>désagréables</quote>
+ devraient être diminués car :
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Les événements dans &pglistener; sont seulement générés lorsque
+ les mise à jours de réplication sont relativement rare, ce qui devrait
+ impliquer que les systèmes chargés ne vont pas générer beaucoup de
+ lignes mortes dans cette table.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Le système va périodiquement faire un troncage (en utilisant
+ <command>TRUNCATE</command> pour nettoyer l'ancienne table) entre les
+ deux tables de logs, <xref linkend="table.sl-log-1"/> et <xref
+ linkend="table.sl-log-2"/>, évitant une croissance illimitée de
+ l'espace <quote>mort</quote> à cet endroit.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para>
+ Les règles de <link linkend="failover">bascule en urgence</link>
+ devraient être planifiées à l'avance.
+ </para>
+
+ <para>
+ Cela peut simplement se résumer à réfléchir à une liste de priorités
+ indiquant qui devrait basculer vers quoi, plutôt que d'essayer
+ d'automatiser la bascule. Quoiqu'il en soit, savoir au préalable ce
+ qu'il faut faire réduit le nombre d'erreurs commises.
+ </para>
+
+ <para>
+ Chez Afilias, une grande variété de guides internes, tel que <citation>Le
+ guide de l'administrateur réveillé à 3 heures du matin...</citation>, ont
+ été rédigé pour fournir les procédures à suivre en cas d'événements
+ <quote>malheureux</quote>. Ce genre de matériel est hautement spécifique
+ à l'environnement et à l'ensemble d'applications présentes, donc vous
+ devriez rédiger vos propres documents. Ceci est un des composants vitaux
+ de tout procédure de reprise après crash.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <xref linkend="stmtmoveset"/> doit être utlisé pour la maintenance
+ préventive afin d'éviter l'apparition des problèmes nécessitant une
+ <link linkend="failover">bascule après panne (« failover »)</link>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ La politique de <command>VACUUM</command> doit être définie avec soin.
+ </para>
+
+ <para>
+ Comme indiqué précédemment, <quote>les transactions longues sont
+ maléfiques</quote>. La commande <command>VACUUM</command> n'est pas
+ une exception à cette règle. Un <command>VACUUM</command> sur une grande
+ table ouvrira une transaction longue qui aura tous les effets négatifs
+ déjà cités.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Il a été prouvé qu'il est préférable d'exécuter tous les démons &lslon;
+ sur un serveur central pour chaque sous-réseau.
+ </para>
+
+ <para>
+ Chaque &lslon; doit être hébergé par hôte sur le même réseau local que
+ le nœud qu'il opère car il envoie <emphasis>beaucoup</emphasis>
+ de communications avec sa base de donnée et que la connexion doit être
+ aussi fiable que possible.
+ </para>
+
+ <para>
+ En théorie, les <quote>meilleures</quote> performances sont prévues
+ lorsque l&lslon; fonctionne sur le même serveur que la base qu'il opère.
+ </para>
+
+ <para>
+ En pratique, déployer les processus &lslon; et leur configuration à
+ travers un réseau d'une douzaine de serveurs se révèle être
+ difficilement gérable.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Les processus &lslon; doivent évoluer dans le même <quote>contexte
+ réseau</quote> que le nœud d'origine, afin que la liaison entre
+ eux soit une connexion <quote>locale</quote>. N'établissez
+ <emphasis>pas</emphasis> ce genre de liaison à travers un réseau WAN.
+ </para>
+
+ <para>
+ Une coupure de lien WAN peut provoquer des connexions
+ <quote>zombies</quote>, et le comportement typique du TCP/IP consiste à
+ <link linkend="multipleslonconnections">laisser ces connexions persister,
+ empêchant le démon slon de redémarrer pendant environ deux heures</link>.
+ </para>
+
+ <para>
+ Il n'est pas difficile de remédier à cela. Vous devez simplement tuer les
+ processus liés aux connexions persistantes avec la commande <command>kill
+ SIGINT</command>. Cependant en exécutant les &lslon; localement, vous
+ êtes généralement à l'abri de ce genre de problèmes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si vous rencontrez ce genre de problèmes, avant de vous exciter, essayez
+ de tuer et redémarrer tous les processus &lslon;. Historiquement, cette
+ méthode a souvent résolu ce genre de <quote>petit tracas.</quote>.
+ </para>
+
+ <para>
+ À quelques rares exceptions, il n'est pas très grave de tuer et relancer
+ les processus &lslon;. Chaque &lslon; se connecte à la base de données
+ qu'il gère, puis ouvre les connexions nécessaires à la propagation des
+ événements. Si vous tuez un &lslon;, vous provoquez simplement
+ l'interruption de ces connexions. Si un évènement <command>SYNC</command>
+ ou un autre événement est en cours de propagation, il n'y a pas de
+ problème : la transaction sera annulée (via un ROLLBACK) et lorsque
+ le &lslon; sera relancé, l'évènement sera retraité à partir de zéro.
+ </para>
+
+ <para>
+ L'exception qui rend un redémarrage de &lslon; indésirable est le cas où
+ une commande <command>COPY_SET</command> est en cours d'exécution sur un
+ grand ensemble de réplication. Dans ce genre de cas, arrêter un &lslon;
+ peut annuler plusieurs heures de travail.
+ </para>
+
+ <para>
+ Dans les premières versions de &slony1;, il était fréquent que des
+ connexions soient un peu <quote>dérangées</quote>, ce qu'on pouvait
+ réparer en redémarrant &lslon;. Ceci est devenu nettement plus rare mais
+ il est parfois utile de redémarrer &lslon;. En cas de <quote>panne
+ réseau</quote>, cela peut résoudre le problème des connexions défuntes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ La section sur les <link linkend="ddlchanges">changements de modèle de
+ données</link> détaille quelques bonnes pratiques qui sont utiles
+ lorsqu'on souhaite modifier le schéma de la base de données.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Gestion des clefs primaires.
+ </para>
+
+ <para>
+ Comme précisé dans la section <link linkend="definingsets">Ensembles de
+ réplication</link>, il est <emphasis>idéal</emphasis> que chaque table
+ répliquée dispose d'une vraie contrainte de clef primaire ; il est
+ <emphasis>acceptable</emphasis> d'utiliser une <quote>clef primaire
+ candidate</quote>.
+ </para>
+
+ <para>
+ Il n'est <emphasis>pas recommandé</emphasis> d'utiliser une clef définie
+ par &slony1; (créée par <xref linkend="stmttableaddkey"/>) pour proposer
+ une clef primaire candidate car cela introduit la possibilité d'échecs de
+ certaines mises à jour sur la table à cause de l'index unique de cette
+ clef. Ceci entraînerait potentiellement des bogues dans votre application
+ à cause de &slony1;.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ La section <link linkend="definesets">Définir les ensembles de
+ réplication</link> vous suggère des stratégies pour déterminer comment
+ regrouper les tables et les séquences en ensembles de réplication.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Il est évident que les actions qui peuvent supprimer beaucoup de données
+ doivent être effectuées avec le plus grand soin. La section <link
+ linkend="dropthings">Supprimer des éléments de la réplication</link>
+ évoque les différentes sortes de <quote>suppression</quote> que &slony1;
+ supporte.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><link linkend="locking">Problèmes d'inter-blocages</link></para>
+
+ <para>
+ Certaines opérations &slony1;, notament <link
+ linkend="stmtsetaddtable"><command>set add table</command></link>,
+ <link linkend="stmtmoveset"><command> move set</command></link>,
+ <link linkend="stmtlockset"><command> lock set </command></link>
+ et <link linkend="stmtddlscript"><command>execute script</command></link>
+ nécessitent l'acquisition de <emphasis>verrous exclusifs</emphasis> sur
+ les tables répliquées.
+ </para>
+
+ <para>
+ En fonction de type d'activité de votre base de données, cela peut (ou
+ pas) provoquer des coupures de services (heureusement assez brèves).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Que faire des ordres DDL ?</para>
+
+ <para>
+ &slony1; fonctionne en détectant les mises à jour sur les tables grâce à
+ des triggers qui sont placés sur ces tables. Cela implique que les mises
+ à jours que se font au moyen de méthodes qui ne déclenchent pas les
+ triggers ne seront pas propagées. Les commandes <command>ALTER
+ TABLE</command>, <command>CREATE OR REPLACE FUNCTION</command>,
+ <command>CREATE TABLE</command> sont toutes des requêtes SQL que &slony1;
+ ne peut pas détecter.
+ </para>
+
+ <para>
+ Pour ce genre de situation, la philosophie de &slony1; consiste à
+ considérer que les développeurs compétents n'écrivent jamais de code
+ auto-modifiant et en particulier du code modifiant les modèles de
+ données à la volée. &slony1; ne cherche pas à faciliter ce genre de
+ modification du schéma de données.
+ </para>
+
+ <para>
+ Cependant, il existe des cas où cela est nécessaire, ainsi <link
+ linkend="stmtddlscript"><command>execute script</command> est fournie
+ pour appliquer des changements DDL au même point dans le flux de
+ transactions sur tous les serveurs</link>.
+ </para>
+
+ <para>
+ Malheureusement, cela provoque de nombreux verrous sur les objets de
+ la base de données. Modifier les tables nécessite l'acquisition d'un
+ verrou exclusif sur ces objets ; ainsi le <command>script
+ d'exécution des modifications</command> entraîne un verrou exclusif sur
+ <emphasis>toutes</emphasis> les tables répliquées. Cela peut s'avérer
+ très problématique lorsque les applications fonctionnent ; des
+ inter-blocages (« deadlocks ») peuvent alors se produire.
+ </para>
+
+ <para>
+ Une position particulièrement dogmatique défendue par certains consiste à
+ dire qu'il faut <emphasis>toujours</emphasis> propager les changements de
+ modèles de données avec un <command>script d'exécution</command>. Cela
+ garantit que les nœuds restent cohérents. Cependant, le coût des
+ verrous et des inter-blocages est trop élevé pour certains utilisateurs.
+ </para>
+
+ <para>
+ Chez Afilias, notre approche est moins dogmatique ; il y a
+ <emphasis>certains</emphasis> changements qui <emphasis>doivent</emphasis>
+ être appliqués avec un <command>script d'exécution</command> mais nous
+ appliquons certaines modifications de manière indépendante.
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Liste de changements qui doivent être effectuée dans un
+ <command>script d'exécution</command> :
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Toutes les commandes <command>ALTER TABLE</command>.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para>
+ Listes des changement qui ne nécessitent pas un <command>script
+ d'exécution</command> :
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <command>CREATE INDEX</command>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>CREATE TABLE</command>
+ </para>
+
+ <para>
+ Les tables qui ne sont pas répliquées n'ont pas besoin de ces
+ mécanismes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>CREATE OR REPLACE FUNCTION</command>
+ </para>
+
+ <para>
+ Typiquement, le chargement de nouvelles version de fonctions peut
+ être effectuée sans que &slony1; en soit <quote>averti</quote>. À
+ l'exception évidente des cas où la nouvelle fonction est déployée
+ suite à la modification d'une table. Dans ce cas-là, la nouvelle
+ version doit être déployée de manière synchronisée avec le
+ <command>script d'exécution</command> qui modifie la table.
+ </para>
+
+ <para>
+ De la même manière, les ordres <command>CREATE TYPE</command>,
+ <command>CREATE AGGREGATE</command>, etc. n'ont pas besoin
+ d'être forcément insérés de manière <quote>parfaitement
+ synchronisés</quote> sur l'ensemble des nœuds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Les ordres de gestion des autorisations, tels que <command>CREATE
+ USER</command>, <command> CREATE ROLE </command>,
+ <command>GRANT</command>, etc. sont inutiles pour &slony1; car
+ ce dernier est exécuté avec les droits de
+ <quote>super-utilisateur</quote>.
+ </para>
+
+ <para>
+ Dans la pratique, il est utile d'avoir différentes politiques de
+ sécurité sur les nœuds. L'accès au nœud
+ <quote>maître</quote> doit être limité aux applications qui en
+ ont réellement besoin. Les utilisateurs effectuant de l'extraction
+ de données (« reporting ») ont généralement des droits
+ plus limités sur le nœud maître que sur les nœuds
+ abonnés.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem id="slonyuser">
+ <para>
+ Noms d'utilisateur spécifiques à &slony1;.
+ </para>
+
+ <para>
+ Il s'est avéré utile de définir un utilisateur <command>slony</command>
+ employé uniquement par &slony1;, un utilisateur distinct de l'utilisateur
+ générique <command>postgres</command> ou <command>pgsql</command>.
+ </para>
+
+ <para>
+ Lorsque toutes sortes d'activités de <quote>maintenance</quote>
+ automatiques, telles que les <command>VACUUM</command> et les sauvegardes,
+ sont effectuées avec l'<quote>identité</quote> de l'utilisateur &postgres;,
+ cela peut assez facilement provoquer des problèmes d'inter-blocages
+ (« deadlocks »).
+ </para>
+
+ <para>
+ Par exemple, une série de <command>VACUUM</command> qui sont lancés de
+ manière inattendue sur une base de donnée avec un gros événement
+ <command>SUBSCRIBE_SET</command> en cours d'exécution peut entraîner des
+ inter-blocages qui peuvent annuler plusieurs heures de travail de copie
+ de données.
+ </para>
+
+ <para>
+ À l'inverse, si les différentes opérations de maintenance sont exécutées
+ par différents utilisateurs, vous pourrez assurer la réussite d'une
+ opération vitale telle que <command>SUBSCRIBE_SET</command>, en bloquant
+ les autres utilisateurs au niveau du fichier
+ <filename>pg_hba.conf</filename>, et en autorisant uniquement
+ l'utilisateur slony, ce qui réduit considérablement les risques lors
+ d'une souscription.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Configuration des chemins</para>
+
+ <para>
+ La section sur les <link linkend="plainpaths">voies de
+ communications</link> évoque les problèmes liés aux connexions réseau
+ nécessaires au bon fonctionnement de &slony1;.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Réduction des super-pouvoirs</para>
+
+ <para>
+ Traditionellement, on considère que <quote>&slony1; a besoin de
+ connexions en mode super-utilisateur</quote>. Cela n'est pas totalement
+ vrai et si l'usage excessif de comptes super-utilisateurs pose problème,
+ il est possible de réduire nettement cet usage.
+ </para>
+
+ <para>
+ Il est vrai que chaque &lslon; <emphasis>doit</emphasis> avoir une
+ connexion super-utilisateur afin de gérer le nœud qu'il opère.
+ Il doit pouvoir modifier le catalogue système afin de mettre en place les
+ abonnements et procéder aux modifications (<emphasis>par exemple</emphasis>
+ pour exécuter <xref linkend="stmtddlscript"/> et d'autres évènement qui
+ peuvent modifier le rôle d'une tables répliqué sur un nœud local).
+ </para>
+
+ <para>
+ Toutefois, les connexions que les processus &lslon; ouvrent vers d'autres
+ nœuds afin d'accéder aux événements et aux souscriptions n'ont pas
+ besoin d'avoir d'autant de droits. Ainsi, on peut mettre en place un
+ <quote>utilisateur faible</quote> assigné à toutes les requêtes <xref
+ linkend="stmtstorepath"/>. Les droits minimaux de cet utilisateur,
+ appellons-le <command>weakuser</command>, sont les suivantes :
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Il doit avoir accès en lecture sur le schéma spécifique de &slony1; ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Il doit avoir accès en lecture sur toutes les tables et les séquences
+ de ce schéma ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Il doit avoir accès en écriture sur la table <envar>sl_nodelock</envar>
+ et la séquence <envar>sl_nodelock_nl_conncnt_seq</envar> ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Lors de la souscrition, il doit avoir accès en lecture sur toutes les tables répliquées.
+ </para>
+
+ <para>
+ Après la souscription, il n'est plus nécessaire d'accéder aux tables répliquées.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Il est parfois nécessaire de lire les tables dans pg_catalog sans
+ qu'on ait pu vérifier le niveau d'accès convenable.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para>
+ Dans la version 1.3, les tests du <xref linkend="testbed"/> permettent
+ l'utilisation d'un utilisateur faible (<envar>WEAKUSER</envar>) afin de
+ tester si les droits définis sont suffisants pour supporter la
+ réplication.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ La section sur les <link linkend="listenpaths">voies d'écoute</link>
+ parle des problèmes entourant la table <xref
+ linkend="table.sl-listen"/>.
+ </para>
+
+ <para>
+ À partir de la version &slony1; 1.1, le contenu de cette table était
+ calculé automatiquement en se basant sur les informations dont disposait
+ &slony1;, ce qui devrait supprimer les problèmes rencontrés. Beaucoup de
+ problèmes de communication inexplicables, avec des nœuds qui
+ n'arrivent pas à se parler alors que c'est techniquement possible,
+ étaient du à une configuration incorrecte des voies d'écoutes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Utilisez <filename>test_slony_state.pl</filename> pour rechercher les
+ problèmes de configuration.
+ </para>
+
+ <para>
+ Il s'agit d'un script Perl qui se connecte à un nœud &slony1; puis
+ parcourt la configuration &slony1; à la recherche de différentes
+ conditions qui indiquent la présence de problèmes, en particulier :
+ </para>
+
+ <itemizedlist>
+ <listitem><para>le gonflement de certaines tables de congfiguration ;</para></listitem>
+ <listitem><para>l'analyse des voies d'écoute ;</para></listitem>
+ <listitem><para>l'analyse de la propagation et de la confirmation des événements.</para></listitem>
+ </itemizedlist>
+
+ <para>
+ Si, de manière mystérieuse, la réplication <quote>ne marche pas</quote>,
+ cet outil peut vérifier beaucoup de problèmes potentiels pour vous.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Configurer &lslon;</para>
+
+ <para>
+ À partir de la version 1.1, la configuration de &lslon; peut être
+ définie par ligne de commande ou dans des fichiers de configuration.
+ De <quote>bonnes</quote> pratiques sont conseillées dans les deux
+ cas :
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Configuration via les options en ligne de commande</para>
+
+ <para>
+ Cette approche a le mérite de rendre visible dans l'environnement
+ système toutes les options actives. Ainsi, s'il y en a beaucoup,
+ cela peut devenir pénible à lire.
+ </para>
+
+ <para>
+ Malheureusement, si vous invoquez &lslon; à partir d'une ligne de
+ commande, vous pouvez <emphasis>oublier</emphasis> d'inclure la
+ configuration de &logshiplink; et ainsi détruire les séquences de
+ logs pour les nœuds de log shipping.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ À la différence des options en ligne de commande, les options
+ actives ne sont <emphasis>pas</emphasis> visibles. Elles peuvent
+ seulement être positionnées à partir du nom et du contenu du
+ fichier de configuration de &lslon; et ne refléteront pas les
+ changements apparus dans le fichier de configuration.
+ </para>
+
+ <para>
+ En plaçant les options dans un fichier, vous n'en oublierez aucune,
+ ce qui est plus sûr pour &logshiplink;.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para>Taches à faire lorsqu'on abonne un nœud</para>
+
+ <para>
+ Lorsqu'un nouveau nœud exécute l'événement
+ <command>COPY_SET</command> sur un grand ensemble de réplication
+ (<emphasis>par exemple</emphasis> un ensemble qui nécessite un
+ abonnement de plusieurs heures), il est prouvé qu'il est souhaitable de
+ verrouiller l'accès au nœud pour tous les utilisateurs autres que
+ <command>slony</command> car :
+ </para>
+ </listitem>
+</itemizedlist>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Les applications s'exécutent sur des données partiellement copiées
+ qui ne seront pas cohérentes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Il est possible que certaines applications (et certains scripts de
+ maintenance) soumettent une combinaison de requêtes qui placeront
+ le système dans une situation d'inter-blocage
+ (« deadlock »), ce qui annulera l'événement
+ <command>COPY_SET</command> et impliquera le ré-abonnement complet
+ du nœud.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Il <emphasis>peut</emphasis> être intéressant de désactiver la fonctionnalité
+ <function>fsync</function> de &postgres; pendant la copie des données, car cela
+ améliorera les performances, et en cas d'échec lors de l'évènement
+ <command>COPY_SET</command>, vous pourrez redémarrer avec une copie entière de
+ l'ensemble de réplication.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>Gestion de slonik</para>
+
+ <para>
+ Les notes sur l'<link linkend="usingslonik">utilisation de Slonik</link>
+ décrivent certaines leçons apprises en gérant un grand nombre de scripts
+ <xref linkend="slonik"/>.
+ </para>
+
+ <para>
+ Voici les principes importants dégagés lors de la création de ces
+ scripts :
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Utiliser des fichiers <quote>préambule</quote> est <emphasis>hautement
+ recommandé</emphasis> car cela implique que vous utilisiez et
+ réutilisiez des préambules vérifiés maintes fois.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Toute opportunité de générer automatiquement la configuration soit en
+ la récupérant dans une base de données, soit en utilisant un script
+ de génération vous aidera à éviter les erreurs humaines.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para>
+ Gérer un très grand ensemble de réplication.
+ </para>
+
+ <para>
+ Certains utilisateurs ont bâti des réplications sur des ensembles de
+ plusieurs dizaines, voire plusieurs centaines de gigaoctets, ce qui
+ ajoute des <quote>contraintes</quote> sur le système, en particulier
+ lorsqu'il faut plusieurs jours pour effectuer un évènement
+ <command>COPY_SET</command>. Voici quelques principes qui ont été définis
+ pour gérer ce genre de situations.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Supprimer tous les index autres que les index primaires lorsque l'évènement
+ en <command>COPY_SET</command> est exécuté.
+ </para>
+
+ <para>
+ Lorsque les données sont copiées dans une table qui dispose d'index,
+ &postgres; construit les index de manière incrémentale, à la volée. Ceci
+ est beaucoup plus lent que simplement copier les donnés dans une table
+ puis de recréer chaque index <quote>ex nihilo</quote> car cette dernière
+ opération profite de l'avantage de la mémoire de tri.
+ </para>
+
+ <para>
+ Dans &slony1; version 1.1.5 et dans les versions ultérieures, les index
+ sont supprimés et recréés automatiquement, ce qui rend caduque ce conseil.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si beaucoup de mises à jour ont lieu lorsque de grands ensembles sont
+ copiés, ceci peut mener à un nombre énorme d'événements
+ <command>SYNC</command> sur le nœud qui s'abonne.
+ </para>
+
+ <para>
+ Si un <command> SYNC </command> est généré une fois par seconde, ceci
+ conduit à un <quote>retard</quote> de plus de 90 000
+ <command>SYNC</command> par jour, pendant probablement plusieurs jours.
+ </para>
+
+ <para>
+ Parallèlement, on constate une croissance <emphasis>énorme</emphasis>
+ des tables <xref linkend="table.sl-log-1"/> et <xref
+ linkend="table.sl-seqlog"/>. Malheureusement, une fois que
+ <command>COPY_SET</command> est terminé, on constate que les requêtes
+ sur ces tables se font via des <command>parcours séquentiels</command>.
+ Même si le <command>SYNC</command> ne traite qu'une petite partie de
+ ces 90 000 événements <command>SYNC</command>, la table sera lue
+ dans son ensemble. Dans de tels cas, il est possible que le nœud
+ abonné ne rattrape jamais le nœud origine.
+ </para>
+
+ <para>
+ Plusieurs taches peuvent résoudre ce problème, notamment en réglant avec
+ soin les paramètres &lslon; :
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Assurez-vous qu'il existe sur le nœud <quote>maître</quote>
+ un index sur <function>sl_log_1(log_xid)</function>. S'il n'y en a pas,
+ comme avec les versions de &slony1; inférieures à la version 1.1.1,
+ regardez dans le fichier <filename>slony1_base.sql</filename> pour la
+ configuration correcte de cet index.
+ </para>
+
+ <para>
+ Dans les versions 1.2 et suivantes, il y a un processus qui ajoute
+ automatiquement les index partiels par numéro de nœud d'origine,
+ ce qui est la forme optimale pour ces index.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Sur un nœud abonné, ajoutez le nombre d'évènements
+ <command>SYNC</command> traités ensemble, en réglant le paramètre
+ <xref linkend= "slon-config-sync-group-maxsize"/> à une valeur lui
+ permettant une portion significative de la masse d'événements
+ <command>SYNC</command>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Sur le nœud abonné, réglez le paramètre <xref
+ linkend="slon-config-desired-sync-time"/> à 0 car le système de
+ regroupement adaptatif des <command>SYNC</command> fonctionne avec de
+ petits groupes qui, sous certaines circonstances, donne de mauvaises
+ performances.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Augmenter le <xref linkend="slon-config-sync-interval"/> sur le
+ nœud origine <xref linkend="slon"/> afin que les événements
+ <command>SYNC</command> soient générés moins fréquemment. Si un
+ <command>SYNC</command> est simplement généré une fois par minute plutôt
+ qu'une fois par seconde, cela divisera par soixante le nombre
+ d'évènements.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Il faudra probablement utiliser le <xref linkend="slon-config-vac-frequency"/>
+ pour désactiver les VACUUM lancés par <xref linkend="slon"/> afin
+ d'utiliser vos propres scripts de VACUUM car il y aura une masse de
+ données non purgeables pendant que les données seront copiées et que
+ l'abonné commencera à rattraper le fournisseur.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect1>
Deleted: traduc/tags/slony_1_2_12/defineset.xml
===================================================================
--- traduc/trunk/slony/defineset.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/defineset.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,314 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="definingsets">
-<title>Définir les ensembles de réplication</title>
-<indexterm><primary>définir les ensembles de réplication</primary></indexterm>
-
-<para>
- En définissant les nœuds, on a conçu l'architecture du cluster de
- réplication ; il est temps de déterminer quelles données doivent être
- copiées entre les nœuds. Les groupes de données qui sont copiés sont
- nommés <quote>ensembles de réplication</quote>.
-</para>
-
-<para>
- Un ensemble de réplication comprend :
-</para>
-
-<itemizedlist>
-
- <listitem>
- <para>
- Les clefs des tables à répliquer qui n'ont pas de clef primaire
- possible ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- Les tables qui doivent être répliquées ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- Les séquences qui doivent être répliquées.
- </para>
- </listitem>
-</itemizedlist>
-
-<sect2><title>Les clefs primaires</title>
-<indexterm><primary>importance des clefs primaires</primary></indexterm>
-
-<para>
- &slony1; <emphasis>a besoin</emphasis> d'une clef primaire ou d'un ensemble
- de champ éligible au statut de clef primaire pour chacune des tables qui
- seront répliquées. Les valeurs de clefs primaires (acronyme « PK »)
- sont utilisées comme identifiant primaire pour chaque ligne qui est modifiée
- sur le système source. Notons que les clefs primaires peuvent être des clefs
- composées de plusieurs colonnes NOT NULL ; elles ne doivent pas
- obligatoirement être constituées de champs uniques. Il y a trois façons de
- préciser à &slony1; quelle clef primaire utiliser :
-</para>
-
-<itemizedlist>
-
- <listitem>
- <para>
- Si la table a déjà une clef primaire identifiée, <xref
- linkend="stmtsetaddtable"/> peut être utilisé sans qu'il soit nécessaire
- de préciser la clef primaire. &slony1; peut automatiquement comprendre
- qu'il existe une clef primaire et l'utiliser.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si la table ne dispose pas d'une clef primaire mais a une clef primaire
- <emphasis>candidate</emphasis>, c'est-à-dire un index sur une combinaison
- de champs qui sont à la fois UNIQUE et NOT NULL, alors vous pouvez
- spécifier cette clef comme ceci :
- </para>
-
-<programlisting>
-SET ADD TABLE (set id = 1, origin = 1, id = 42,
- full qualified name = 'public.ma_table',
- key = 'ma_table_idx',
- comment='ma_table_idx est une clef primaire candidate de ma_table');
-</programlisting>
-
- <para>
- Cependant, une fois arrivé à cette étape, pourquoi ne pas déclarer l'index
- comme une clef primaire, ce qui nécessite que les colonnes impliquées soient
- NOT NULL, et ce qui constituera un index unique. Voici un exemple :
- </para>
-
-<programlisting>
-DROP INDEX ma_table_nom_col1_col2_uniq_idx;
-ALTER TABLE ma_table_nom ADD PRIMARY KEY (col1, col2);
-</programlisting>
-
- <para>
- Si votre application utilise l'index ma_table_nom, vous ne perdrez rien et
- cela vous donnera l'avantage d'avoir une clef primaire sur votre table.
- </para>
-
- <para>
- Notons que si vous devez spécifier un espace de nom (« namespace »)
- pour la table, vous <emphasis>ne devez pas</emphasis> préciser l'espace de
- nom de la clef car cela peut interférer avec d'autres espaces de noms de la
- table.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si la table n'a pas de clef primaire candidate, vous devez demander à
- &slony1; d'en produire une en utilisant la commande <xref
- linkend="stmttableaddkey"/>.
- </para>
-
- <warning>
- <para>
- La commande <xref linkend="stmttableaddkey"/> a toujours été considérée
- au mieux comme un <quote>bricolage</quote>, et à partir de la version
- 2.0, elle est considérée comme une mauvaise fonctionnalité qu'il faut
- supprimer.
- </para>
- </warning>
- </listitem>
-</itemizedlist>
-
-<para>
- Il n'est pas terriblement important de sélectionner une <quote>vraie</quote>
- clef primaire ou une simple <quote>clef primaire</quote>. Cependant, il est
- fortement recommandé d'utiliser une de ces deux solutions plutôt que de
- laisser &slony1; remplir la colonne de clef primaire à votre place. Si vous
- n'avez pas de clef primaire candidate, cela signifie que la table ne fournit
- aucun mécanisme à votre application pour garder les lignes uniques. Dans ce
- cadre, &slony1; peut introduire des erreurs dans votre application. De plus,
- cela implique que vous pouvez entrer des données erronées dans la base de
- données.
-</para>
-
-</sect2>
-
-<sect2 id="definesets">
-<title>Regrouper les tables en ensembles</title>
-<indexterm><primary> grouper les tables dans des ensembles de réplication </primary></indexterm>
-
-<para>
- Il est vital de regrouper les tables dans un seul ensemble lorsque ces tables
- sont reliées par une clef étrangère. Si des tables reliées de cette manière
- ne sont <emphasis>pas</emphasis> répliquées ensembles, vous rencontrerez des
- problèmes lors de la bascule du nœud <quote>fournisseur maître</quote>
- vers un autre nœud, et vous obtiendrez un nouveau <quote>maître</quote>
- qui ne peut pas être mis à jour correctement car le contenu de certaines
- tables n'est pas disponible.
-</para>
-
-<para>
- Il y a également plusieurs raisons pour ne <emphasis>pas</emphasis> placer
- toutes les tables dans un ensemble unique :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Sur un ensemble très large, l'événement initial
- <command>COPY_SET</command> provoque de <link
- linkend="longtxnsareevil">très longues transactions</link> sur le
- nœud fournisseur. La <link linkend="faq">FAQ</link> décrit un
- certain nombre de problèmes qui conduisent à des transactions qui
- ralentissent les performances du système.
- </para>
-
- <para>
- Si vous pouvez découper un grand ensemble en plusieurs plus petits
- ensembles, cela réduira la longueur de chaque transactions et diminuera
- leur impact négatif sur les performances.
- </para>
-
- <para>
- Un autre problème survient fréquemment lorsque l'on réplique via un
- WAN ; parfois la connexion réseau est un peu instable, si bien
- qu'il y a des risques qu'une connexion reste ouverte pendant plusieurs
- heures et entraîne un <command>CONNECTION TIMEOUT</command>. Si cela se
- produit à 95% d'une copie d'un ensemble de réplication de 50 tables,
- représentant 250GB de données, cela va gâcher votre journée. Au contraire
- si les tables sont séparées en plusieurs ensembles de réplication, cette
- panne réseau qui intervient à 95% n'interrompra que la copie
- d'<emphasis>un seul</emphasis> ensemble.
- </para>
-
- <para>
- Certains <quote>effets négatifs</quote> surviennent lorsque la base de
- données répliquée contient plusieurs Go de données, et qu'il faut des
- heures ou des jours pour qu'un nœud abonné réalise une copie
- complète des données initiales. Pour les bases relativement petites,
- cela n'est pas un facteur important.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Chaque invocation de la commande <xref linkend="stmtddlscript"/>
- nécessite un verrou sur <emphasis>chaque table de l'ensemble de
- réplication, d'abord sur le nœud d'origine puis, avec la
- propagation de l'événement, sur chacun des nœuds abonnés
- </emphasis>.
- </para>
-
- <para>
- Des retours d'expériences <quote>de terrain</quote> indiquent que cela
- peut conduire à des inter-blocages de verrous ("deadlocks"), ce qui
- nécessite d'appeler la requête <xref linkend="stmtddlscript"/> plusieurs
- fois pour réussir à l'exécuter complètement.
- </para>
-
- <para>
- Plus vous avez de tables dans un ensemble de réplication, plus ces tables
- doivent être verrouillées et plus les risques d'obtenir un inter-blocage
- des verrous sont importants.
- </para>
-
- <para>
- Dans le même ordre d'idées, si un script DDL particulier doit simplement
- affecter deux tables, vous devez utiliser <xref
- linkend="stmtsetmovetable"/> pour les déplacer temporairement dans un
- nouvel ensemble de réplication. En diminuant le nombre de verrous
- nécessaire, cela simplifiera la mise en place des changements DDL.
- </para>
-
- <para>
- Il y a de plus amples <link linkend="locking">discussions sur les
- verrous</link> qui décrivent quand &slony1; a besoin de verrous et leur
- impact sur vos applications.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-<sect2> <title>Pathologie des séquences</title>
-<indexterm><primary>Pathologie de séquence</primary></indexterm>
-
-<para>
- Chaque fois qu'un évènement SYNC est traité, les valeurs sont enregistrées
- pour <emphasis>toutes</emphasis> les séquences de l'ensemble de réplication.
- Si vous avez beaucoup de séquences, cela peut augmenter fortement la
- volumétrie de la table <xref linkend="table.sl-seqlog"/> .
-</para>
-
-<para>
- Cela illustre une différence importante entre les tables et les
- séquences : si vous ajoutez des tables supplémentaire qui ont peu
- d'activité, voire aucune, cela n'ajoute pas de charge supplémentaire pour le
- système de réplication. Pour les séquences répliquées, les valeurs doivent
- être <emphasis>régulièrement</emphasis> propagées aux abonnés. Considérons
- les conséquences :
-
- <itemizedlist>
- <listitem>
- <para>
- Une table répliquée mais qui n'est jamais mise à jour n'entraîne pas
- de travail supplémentaire.
- </para>
-
- <para>
- Si elle n'est jamais mise à jour, le trigger de la table sur le
- nœud origine n'est jamais déclenché, et aucune entrée n'est
- ajoutée dans <xref linkend="table.sl-log-1"/>. La table n'apparaît
- jamais dans aucune des requêtes de réplication (<emphasis>par
- exemple :</emphasis> dans les requêtes <command>FETCH 100 FROM
- LOG</command> utilisées pour trouver les données à répliquer) car elles
- ne recherchent que les tables qui ont des entrées dans
- <xref linkend="table.sl-log-1"/>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Au contraire, une certaine quantité de travail est ajoutée lors d'un
- événement SYNC pour chaque séquence qui est répliquée.
- </para>
-
- <para>
- Pour répliquer 300 séquences, 300 lignes doivent être ajoutées dans la
- <xref linkend="table.sl-seqlog"/> de manière régulière.
- </para>
-
- <para>
- Il est probable que si une valeur d'une séquence particulière n'a pas
- changé depuis la dernière vérification, alors il n'est peut-être pas
- nécessaire de stocker cette valeur encore et encore. Certaines
- reflexions sont en cours sur le moyen de réaliser cela de manière
- sécurisée.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Le <ulink
- url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226">
- bug #1226</ulink> indique une condition d'erreur qui peut se produire
- si vous avez un ensemble de réplication composé uniquement de séquences.
- </para>
-
- <para>
- Ceci est documenté plus précisément dans la <link
- linkend="sequenceset">FAQ</link>. En résumé, avoir un ensemble de
- réplication composé uniquement de séquences n'est pas particulièrement
- une bonne idée.
- </para>
- </listitem>
- </itemizedlist>
-</para>
-
-</sect2>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/defineset.xml (from rev 1244, traduc/trunk/slony/defineset.xml)
===================================================================
--- traduc/tags/slony_1_2_12/defineset.xml (rev 0)
+++ traduc/tags/slony_1_2_12/defineset.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,296 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="definingsets">
+<title>Définir les ensembles de réplication</title>
+<indexterm><primary>définir les ensembles de réplication</primary></indexterm>
+
+<para>
+ En définissant les nœuds, on a conçu l'architecture du cluster de
+ réplication ; il est temps de déterminer quelles données doivent être
+ copiées entre les nœuds. Les groupes de données qui sont copiés sont
+ nommés <quote>ensembles de réplication</quote>.
+</para>
+
+<para>
+ Un ensemble de réplication comprend :
+</para>
+
+<itemizedlist>
+
+ <listitem>
+ <para>
+ Les clefs des tables à répliquer qui n'ont pas de clef primaire
+ possible ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Les tables qui doivent être répliquées ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Les séquences qui doivent être répliquées.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<sect2><title>Les clefs primaires</title>
+<indexterm><primary>importance des clefs primaires</primary></indexterm>
+
+<para>
+ &slony1; <emphasis>a besoin</emphasis> d'une clef primaire ou d'un ensemble
+ de champ éligible au statut de clef primaire pour chacune des tables qui
+ seront répliquées. Les valeurs de clefs primaires (acronyme « PK »)
+ sont utilisées comme identifiant primaire pour chaque ligne qui est modifiée
+ sur le système source. Notons que les clefs primaires peuvent être des clefs
+ composées de plusieurs colonnes NOT NULL ; elles ne doivent pas
+ obligatoirement être constituées de champs uniques. Il y a trois façons de
+ préciser à &slony1; quelle clef primaire utiliser :
+</para>
+
+<itemizedlist>
+
+ <listitem>
+ <para>
+ Si la table a déjà une clef primaire identifiée, <xref
+ linkend="stmtsetaddtable"/> peut être utilisé sans qu'il soit nécessaire
+ de préciser la clef primaire. &slony1; peut automatiquement comprendre
+ qu'il existe une clef primaire et l'utiliser.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si la table ne dispose pas d'une clef primaire mais a une clef primaire
+ <emphasis>candidate</emphasis>, c'est-à-dire un index sur une combinaison
+ de champs qui sont à la fois UNIQUE et NOT NULL, alors vous pouvez
+ spécifier cette clef comme ceci :
+ </para>
+
+<programlisting>
+SET ADD TABLE (set id = 1, origin = 1, id = 42,
+ full qualified name = 'public.ma_table',
+ key = 'ma_table_idx',
+ comment='ma_table_idx est une clef primaire candidate de ma_table');
+</programlisting>
+
+ <para>
+ Cependant, une fois arrivé à cette étape, pourquoi ne pas déclarer l'index
+ comme une clef primaire, ce qui nécessite que les colonnes impliquées soient
+ NOT NULL, et ce qui constituera un index unique. Voici un exemple :
+ </para>
+
+<programlisting>
+DROP INDEX ma_table_nom_col1_col2_uniq_idx;
+ALTER TABLE ma_table_nom ADD PRIMARY KEY (col1, col2);
+</programlisting>
+
+ <para>
+ Si votre application utilise l'index ma_table_nom, vous ne perdrez rien et
+ cela vous donnera l'avantage d'avoir une clef primaire sur votre table.
+ </para>
+
+ <para>
+ Notons que si vous devez spécifier un espace de nom (« namespace »)
+ pour la table, vous <emphasis>ne devez pas</emphasis> préciser l'espace de
+ nom de la clef car cela peut interférer avec d'autres espaces de noms de la
+ table.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si la table n'a pas de clef primaire candidate, vous devez demander à
+ &slony1; d'en fournir une. Tout d'abord, vous devez utiliser <xref
+ linkend="stmttableaddkey"/> pour ajouter une colonne peuplée en utilisant
+ une séquence &slony1;. Ensuite, <xref linkend="stmtsetaddtable"/> inclut
+ la directive <option>key=serial</option> pour indiquer que la propre
+ colonne de &slony1; doit être utilisé.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Il n'est pas terriblement important de sélectionner une <quote>vraie</quote>
+ clef primaire ou une simple <quote>clef primaire</quote>. Cependant, il est
+ fortement recommandé d'utiliser une de ces deux solutions plutôt que de
+ laisser &slony1; remplir la colonne de clef primaire à votre place. Si vous
+ n'avez pas de clef primaire candidate, cela signifie que la table ne fournit
+ aucun mécanisme à votre application pour garder les lignes uniques. Dans ce
+ cadre, &slony1; peut introduire des erreurs dans votre application. De plus,
+ cela implique que vous pouvez entrer des données erronées dans la base de
+ données.
+</para>
+
+</sect2>
+
+<sect2 id="definesets">
+<title>Regrouper les tables en ensembles</title>
+<indexterm><primary> grouper les tables dans des ensembles de réplication </primary></indexterm>
+
+<para>
+ Il est vital de regrouper les tables dans un seul ensemble lorsque ces tables
+ sont reliées par une clef étrangère. Si des tables reliées de cette manière
+ ne sont <emphasis>pas</emphasis> répliquées ensembles, vous rencontrerez des
+ problèmes lors de la bascule du nœud <quote>fournisseur maître</quote>
+ vers un autre nœud, et vous obtiendrez un nouveau <quote>maître</quote>
+ qui ne peut pas être mis à jour correctement car le contenu de certaines
+ tables n'est pas disponible.
+</para>
+
+<para>
+ Il y a également plusieurs raisons pour ne <emphasis>pas</emphasis> placer
+ toutes les tables dans un ensemble unique :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Sur un ensemble très large, l'événement initial
+ <command>COPY_SET</command> provoque de <link
+ linkend="longtxnsareevil">très longues transactions</link> sur le
+ nœud fournisseur. La <link linkend="faq">FAQ</link> décrit un
+ certain nombre de problèmes qui conduisent à des transactions qui
+ ralentissent les performances du système.
+ </para>
+
+ <para>
+ Si vous pouvez découper un grand ensemble en plusieurs plus petits
+ ensembles, cela réduira la longueur de chaque transactions et diminuera
+ leur impact négatif sur les performances.
+ </para>
+
+ <para>
+ Certains <quote>effets négatifs</quote> surviennent lorsque la base de
+ données répliquée contient plusieurs Go de données, et qu'il faut des
+ heures ou des jours pour qu'un nœud abonné réalise une copie
+ complète des données initiales. Pour les bases relativement petites,
+ cela n'est pas un facteur important.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Chaque invocation de la commande <xref linkend="stmtddlscript"/>
+ nécessite un verrou sur <emphasis>chaque table de l'ensemble de
+ réplication, d'abord sur le nœud d'origine puis, avec la
+ propagation de l'événement, sur chacun des nœuds abonnés
+ </emphasis>.
+ </para>
+
+ <para>
+ Des retours d'expériences <quote>de terrain</quote> indiquent que cela
+ peut conduire à des inter-blocages de verrous ("deadlocks"), ce qui
+ nécessite d'appeler la requête <xref linkend="stmtddlscript"/> plusieurs
+ fois pour réussir à l'exécuter complètement.
+ </para>
+
+ <para>
+ Plus vous avez de tables dans un ensemble de réplication, plus ces tables
+ doivent être verrouillées et plus les risques d'obtenir un inter-blocage
+ des verrous sont importants.
+ </para>
+
+ <para>
+ Dans le même ordre d'idées, si un script DDL particulier doit simplement
+ affecter deux tables, vous devez utiliser <xref
+ linkend="stmtsetmovetable"/> pour les déplacer temporairement dans un
+ nouvel ensemble de réplication. En diminuant le nombre de verrous
+ nécessaire, cela simplifiera la mise en place des changements DDL.
+ </para>
+
+ <para>
+ Il y a de plus amples <link linkend="locking">discussions sur les
+ verrous</link> qui décrivent quand &slony1; a besoin de verrous et leur
+ impact sur vos applications.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2> <title>Pathologie des séquences</title>
+<indexterm><primary>Pathologie de séquence</primary></indexterm>
+
+<para>
+ Chaque fois qu'un évènement SYNC est traité, les valeurs sont enregistrées
+ pour <emphasis>toutes</emphasis> les séquences de l'ensemble de réplication.
+ Si vous avez beaucoup de séquences, cela peut augmenter fortement la
+ volumétrie de la table <xref linkend="table.sl-seqlog"/> .
+</para>
+
+<para>
+ Cela illustre une différence importante entre les tables et les
+ séquences : si vous ajoutez des tables supplémentaire qui ont peu
+ d'activité, voire aucune, cela n'ajoute pas de charge supplémentaire pour le
+ système de réplication. Pour les séquences répliquées, les valeurs doivent
+ être <emphasis>régulièrement</emphasis> propagées aux abonnés. Considérons
+ les conséquences :
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Une table répliquée mais qui n'est jamais mise à jour n'entraîne pas
+ de travail supplémentaire.
+ </para>
+
+ <para>
+ Si elle n'est jamais mise à jour, le trigger de la table sur le
+ nœud origine n'est jamais déclenché, et aucune entrée n'est
+ ajoutée dans <xref linkend="table.sl-log-1"/>. La table n'apparaît
+ jamais dans aucune des requêtes de réplication (<emphasis>par
+ exemple :</emphasis> dans les requêtes <command>FETCH 100 FROM
+ LOG</command> utilisées pour trouver les données à répliquer) car elles
+ ne recherchent que les tables qui ont des entrées dans
+ <xref linkend="table.sl-log-1"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Au contraire, une certaine quantité de travail est ajoutée lors d'un
+ événement SYNC pour chaque séquence qui est répliquée.
+ </para>
+
+ <para>
+ Pour répliquer 300 séquences, 300 lignes doivent être ajoutées dans la
+ <xref linkend="table.sl-seqlog"/> de manière régulière.
+ </para>
+
+ <para>
+ Il est probable que si une valeur d'une séquence particulière n'a pas
+ changé depuis la dernière vérification, alors il n'est peut-être pas
+ nécessaire de stocker cette valeur encore et encore. Certaines
+ reflexions sont en cours sur le moyen de réaliser cela de manière
+ sécurisée.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Le <ulink
+ url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226">
+ bug #1226</ulink> indique une condition d'erreur qui peut se produire
+ si vous avez un ensemble de réplication composé uniquement de séquences.
+ </para>
+
+ <para>
+ Ceci est documenté plus précisément dans la <link
+ linkend="sequenceset">FAQ</link>. En résumé, avoir un ensemble de
+ réplication composé uniquement de séquences n'est pas particulièrement
+ une bonne idée.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
+
+</sect2>
+
+</sect1>
Deleted: traduc/tags/slony_1_2_12/failover.xml
===================================================================
--- traduc/trunk/slony/failover.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/failover.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,423 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="failover">
-<title>Effectuer une bascule d'urgence avec &slony1;</title>
-<indexterm>
- <primary>bascule d'urgence</primary>
- <secondary>reprise sur panne</secondary>
-</indexterm>
-
-<sect2>
-<title>Avant-propos</title>
-
-<para>
- &slony1; est un système de réplication asynchrone. À cause de cela, il est
- presque certain qu'au moment où le nœud origine d'un ensemble de
- réplication tombe en panne, la dernière transaction <quote>validée</quote>
- sur l'origine ne soit pas encore propagée aux abonnés. Les systèmes qui
- tombent en panne sont souvent soumis à une forte charge ; c'est un
- des corollaires de la loi de Murphy. Ainsi le but principal est
- d'<emphasis>éviter</emphasis> que le serveur principal tombe en panne. La
- meilleure façon d'éviter cela est d'effectuer une maintenance fréquente.
-</para>
-
-<para>
- Ouvrir le capot d'un serveur à chaud n'est pas ce qu'on peut appeler une
- façon <quote>professionelle</quote> d'assurer la maintenance d'un système.
- En général, les utilisateurs qui ont besoin de réplication pour leur
- sauvegarde ou leur plan de reprise sur panne, ont également des critères
- très stricts en matière de <quote>temps d'arrêt du système</quote>. Pour
- répondre à ces critères, &slony1; ne se contente pas de fournir des méthodes
- de reprise sur panne, il intègre également la notion de transfert d'origine.
-</para>
-
-<para>
- On suppose dans cette partie que le lecteur est familier avec l'utilitaire
- <xref linkend="slonik"/> et qu'il sait comment mettre en place un système de
- réplication &slony1; composé de deux nœuds.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Bascule contrôlée</title>
-<indexterm><primary>bascule contrôlée</primary></indexterm>
-
-<para>
- Imaginons un nœud <quote>origine</quote>, appelé nœud1, avec un
- <quote>abonné</quote> appelé nœud2 (l'esclave). Une application web,
- placée sur un troisième serveur, accède à la base de données sur nœud1.
- Les deux bases sont actives et fonctionnelles, la réplication est est à peu
- près synchronisée. On contrôle la bascule avec la commande <xref
- linkend="stmtmoveset"/>.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Au moment ou nous écrivons ces lignes, basculer vers un autre serveur
- nécessite que l'application se reconnecte à la nouvelle base de donnée.
- Donc, pour éviter toute complication, nous éteignons le serveur web. Les
- utilisateurs qui ont installé <application>pgpool</application> pour
- gérer les connexions peuvent simplement éteindre le pool.
- </para>
-
- <para>
- Les actions à mener dépendent beaucoup de la configuration des
- applications qui utilisent la base de données. En général, les
- applications qui étaient connectées à l'ancienne base doivent détruire
- leurs connexions et en établir de nouvelles vers la base qui vient d'être
- promue dans le rôle du <quote>/maître/</quote>. Il y a différentes façons
- de configurer cela, et donc différentes façon d'effectuer la bascule :
-
- <itemizedlist>
- <listitem>
- <para>
- L'application stocke le nom de la base de donnée dans un fichier.
- </para>
-
- <para>
- Dans ce cas, la reconfiguration nécessite de changer la valeur dans
- ce fichier, d'arrêter puis de relancer l'application pour qu'elle
- pointe vers le nouvel emplacement des données.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Une utilisation pertinente de DNS consiste à créer des <ulink
- url="http://www.iana.org/assignments/dns-parameters">champs DNS</ulink>
- CNAME qui permettent à l'application d'utiliser un nom pour
- référencer le nœud qui joue le rôle du nœud
- <quote>maître</quote>.
- </para>
-
- <para>
- Dans ce cas, la reconfiguration nécessite de changer le CNAME pour
- pointer vers le nouveau serveur. De plus, il faut probablement
- relancer l'application pour rafraîchir les connexions à la base.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si vous utilisez <application>pgpool</application> ou un
- <quote>gestionnaire de connexions</quote> similaire, alors la
- reconfiguration implique de modifier le paramètrage de cet outil,
- à part cela la procédure est similaire à l'exemple DNS/CNAME
- ci-dessus.
- </para>
- </listitem>
- </itemizedlist>
- </para>
-
- <para>
- La nécessité de redémarrer l'application qui se connecte à la base dépend
- de la manière dont elle a été conçue et des mécanismes de gestion d'erreurs
- de connexion qui ont été implémentés ; si à la suite d'une erreur
- elle tente d'ouvrir à nouveau une connexion, alors il n'est pas nécessaire
- de la relancer.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Un petit script <xref linkend="slonik"/> exécute les commandes
- suivantes :
-
- <programlisting>lock set (id = 1, origin = 1);
-wait for event (origin = 1, confirmed = 2);
-move set (id = 1, old origin = 1, new origin = 2);
-wait for event (origin = 1, confirmed = 2);</programlisting>
- </para>
-
- <para>
- Après ces commandes, l'origine (rôle du maître) de l'ensemble de
- réplication 1 est transféré sur le nœud 2. En fait, elle n'est
- pas simplement transférée ; le nœud1 devient un abonné
- parfaitement synchronisé et actif. Autrement dit, les deux nœuds
- ont échangé leurs rôles respectifs.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Après la reconfiguration de l'application web (ou de
- <application><link linkend="pgpool">pgpool</link></application>) pour
- qu'elle se connecte à la base du nœud 2, le serveur web est
- redémarré et reprend son activité normale.
- </para>
-
- <para>
- Lorsqu'on utilise un script shell, pour stopper l'application, lancer le
- script <application>slonik</application>, déplacer les fichiers de
- configuration et relancer l'ensemble, toute la procédure prend en général
- moins de 10 secondes.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Vous pouvez désormais éteindre le serveur qui héberge le nœud 1 et
- effectuer les opérations de maintenance requise. Lorsque le démon <xref
- linkend="slon"/> du nœud 1 est redémarré, il reprend la réplication,
- et rattrape son retard. Une fois synchronisé, on peut exécuter la procédure
- à nouveau pour restaurer la configuration originale.
-</para>
-
-<para>
- Ceci est la meilleure méthode pour ce genre d'opération de maintenance ;
- elle s'effectue rapidement, sous le contrôle d'un administrateur, et elle
- n'implique aucune perte de données.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Bascule d'urgence</title>
-<indexterm><primary>bascule suite à une panne du système</primary></indexterm>
-
-<para>
- Lorsque de graves problèmes apparaissent sur le serveur <quote>origine</quote>,
- il est parfois nécessaire d'effectuer une bascule (<xref
- linkend="stmtfailover"/>) vers le serveur de sauvegarde. Ce cas de figure n'a
- rien de souhaitable car les transactions <quote>validées</quote> sur le
- serveur mais pas sur les abonnés, seront perdues. Certaines de ces
- transactions auront peut-être été annoncées à l'utilisateur final comme
- <quote>validées</quote>. En conséquence, les bascules d'urgence doivent être
- considérées comme un <emphasis>dernier recours</emphasis>. Si le serveur
- origine qui subit <quote>l'avarie</quote> peut être maintenu assez longtemps,
- il est <emphasis>nettement</emphasis> préférable d'effectuer une bascule
- contrôlée.
-</para>
-
-<para>
- &slony1; ne fournit pas de moyen pour détecter les pannes du système.
- Abandonner des transactions <quote>validées</quote> est une décision
- commerciale qui ne peut pas être prise par un système de gestion de base de
- données. Si vous voulez placer les commandes ci-dessous dans un script exécuté
- automatiquement par un système de surveillance, ce sont
- <emphasis>vos</emphasis> données, et <emphasis>votre</emphasis> politique de
- bascule d'urgence.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- La commande <xref linkend="slonik"/>
- <programlisting>failover (id = 1, backup node = 2);</programlisting>
- ordonne au nœud 2 de se considérer comme le propriétaire
- (l'origine) de tous les ensembles que le nœud 1 possédait. S'il
- existe des nœuds supplémentaires dans le cluster &slony1;, tous
- les nœuds abonnés au nœud 1 sont avertis du changement.
- <application>Slonik</application> va aussi envoyer une requête
- à chaque abonné pour déterminer le nœud de plus haut niveau de
- synchronisation (<emphasis>c'est-à-dire</emphasis> la dernière
- transaction <quote>validée</quote>) pour chaque ensemble de réplication.
- La configuration sera changée de façon à ce que le nœud 2 applique
- d'abord ces transactions finales, avant d'autoriser l'accès en écriture
- sur les tables.
- </para>
-
- <para>
- De plus, tous les nœuds qui étaient abonnés directement au nœud
- 1 considèreront désormais le nœud 2 comme leur fournisseur de données
- pour cet ensemble de replication. Cela signifie qu'une fois que la commande
- de bascule d'urgence est complétée, plus aucun nœud du cluster ne
- reçoit d'information de la part du nœud 1.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Reconfigurer et relancer l'application (ou
- <application>pgpool</application>) pour qu'elle se reconnecte
- au nœud 2.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Purger le nœud abandonné.</para>
-
- <para>
- Vous découvrirez, après la bascule, qu'il existe encore beaucoup de
- références au nœud 1 dans la table <xref linkend="table.sl-node"/>,
- ainsi que ses tables associées telle que <xref
- linkend="table.sl-confirm"/> ; puisque des données sont toujours
- présentes dans <xref linkend="table.sl-log-1"/>, &slony1; ne peut pas
- purger immédiatement le nœud.
- </para>
-
- <para>
- Une fois que la bascule est complète et que le nœud 2 accepte
- les opérations d'écriture sur les tables répliquées, il faut supprimer
- toutes les informations de configuration rémanentes avec la commande
- <xref linkend="stmtdropnode"/> :
-
- <programlisting>drop node (id = 1, event node = 2);</programlisting>
- </para>
-
- <para>
- Supposons que la panne résulte d'un problème matériel catastrophique sur
- le nœud 1, il est possible qu'il ne <quote>reste</quote> plus rien
- sur le nœud 1. Si la panne n'est pas <quote>totale</quote>, ce qui
- est souvent le cas lors d'une coupure réseau, vous découvrirez que le
- nœud 1 <quote>imagine</quote> toujours que rien n'a changé et qu'il
- est dans le même état qu'avant la panne. Reportez-vous à la section <xref
- linkend="rebuildnode1"/> pour plus de détails sur ce que cela implique.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-<sect2>
-<title>Automatisation de la commande <command>FAIL OVER</command></title>
-<indexterm><primary>automatisation des bascules d'urgence</primary></indexterm>
-
-<para>
- Si vous choisissez d'automatiser la commande <command>FAIL OVER </command>,
- il est important de le faire <emphasis>avec soin</emphasis>. Vous devez être
- sur que le nœud en panne est réellement en panne, et vous devez être
- capable de vous assurer que le nœud en panne ne redémarre pas, ce qui
- entraînerait un conflit entre deux nœuds capables de jouer le rôle du
- <quote>maître</quote>.
-</para>
-
-<note>
- <para>
- Le fait de <quote>tirer une balle dans la tête du serveur en panne</quote>
- ne pose pas directement de problème à la réplication ou à &slony1; ;
- &slony1; supporte cela de manière assez tranquillement car, une fois qu'un
- nœud est marqué comme étant en panne, les autres nœuds
- <quote>l'oublient</quote> et l'ignorent. Le problème se situe plutôt au
- niveau de <emphasis>votre application</emphasis>. Supposons que le
- nœud en panne soit capable de répondre aux requêtes de votre
- application, <emphasis>cela</emphasis> va certainement poser un problème
- qui n'a rien à voir avec &slony1;. Le problème est que deux bases de
- données sont en mesure de répondre en tant que <quote>maître</quote>.
- </para>
-</note>
-
-<para>
- Lorsqu'une bascule d'urgence est effectuée, il faut un mécanisme pour dégager
- de force le nœud en panne hors du réseau afin d'éviter toute confusion
- au niveau des applications. Cela peut être fait via une interface SNMP qui
- effectue une partie des opérations suivantes :
-
- <itemizedlist>
- <listitem>
- <para>Éteindre l'alimentation du serveur en panne.</para>
-
- <para>
- Si l'on ne fait pas attention, le serveur peut réapparaître dans le
- système de réplication si un administrateur le rallume.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Modifier les règles du pare-feu ou d'autres configurations pour exclure
- du réseau l'adresse IP du serveur en panne.
- </para>
-
- <para>
- Si le serveur a de multiples interfaces, et donc de multiple adresses IP,
- cette approche permet de supprimer/désactiver les adresses utilisées
- par l'application, tout en conservant les adresses
- <quote>administratives</quote> afin que le serveur reste accessible par
- les administrateurs systèmes.
- </para>
- </listitem>
- </itemizedlist>
-</para>
-
-</sect2>
-
-<sect2 id="rebuildnode1">
-<title>Après la bascule d'urgence, reconfiguration de l'ancienne origine</title>
-<indexterm><primary>reconstruction après une bascule d'urgence</primary></indexterm>
-
-<para>
- Ce qui arrive au nœud en panne dépend beaucoup de la nature de la
- catastrophe qui a conduit à la bascule d'urgence vers un autre nœud.
- Si le nœud a été abandonné à cause de la destruction physique des
- disques de stockage, il n'y a plus grand-chose à faire. D'un autre coté,
- si un nœud a été abandonné à cause d'une coupure réseau, qui n'a pas
- perturbé le fonctionnement normal du nœud <quote>fournisseur</quote>.
- Toutefois, une fois que les communications sont restaurées, le fait est que
- la commande <command>FAIL OVER</command> rend obligatoire l'abandon du
- nœud qui était en panne.
-</para>
-
-<para>
- Après ce genre de bascule d'urgence, les données stockées sur le nœud 1
- seront rapidement et de plus en plus désynchronisées par rapport aux autres
- nœuds. Elles doivent être considérées comme corrompues. Ainsi le seul
- moyen pour que le nœud 1 retourne dans le cluster de réplication et
- qu'il redevienne le nœud origine est de le reconstruire à partir de
- zéro comme un abonné, de le laisser rattraper son retard, puis d'effectuer
- la procédure de bascule contrôlée.
-</para>
-
-<para>
- Une bonne raison de <emphasis>ne pas</emphasis> faire cela automatiquement
- est que d'importantes mises à jour (d'un point de vue
- <emphasis>commercial</emphasis>) ont pu être <quote>validées</quote> sur le
- système en panne. Vous souhaiterez probablement analyser les dernières
- transactions que le nœud a réalisé avant de tomber en panne, afin de
- voir si certaines doivent être ré-appliquer sur le cluster
- <quote>actif</quote>. Par exemple, si quelqu'un réalisait des opérations
- bancaires impactant des comptes clients au moment de la panne, il est
- souhaitable de ne pas perdre cette information.
-</para>
-
-<warning>
- <para>
- On a observé certains résultats étranges lorsqu'un nœud <quote>tombe
- en panne</quote> à cause d'une coupure réseau persistante, par opposition
- aux pannes du système de stockage. Dans de tels scénarios, le nœud
- <quote>en panne</quote> dispose d'une base de données en parfait état de
- marche ; le fait est qu'ayant été coupé des autres nœuds, il
- <quote>crie en silence</quote>.
- </para>
-
- <para>
- Lorsque la connexion réseau est réparée, ce nœud peut réapparaître et
- conformément à <emphasis>sa</emphasis> configuration, il va communiquer
- avec les autres nœuds du cluster &slony1;.
- </para>
-
- <para>
- En <emphasis>fait</emphasis>, la confusion se trouve uniquement sur ce
- nœud. Les autres nœud du cluster ne sont pas du tout
- perturbés ; ils savent que ce nœud est <quote>mort</quote> et
- qu'ils doivent l'ignorer. Mais il est impossible de savoir cela en
- regardant le nœud qui était <quote>en panne</quote>.
- </para>
-
- <para>
- Ceci nous ramène au fait que &slony1; n'est pas un outil de surveillance de
- réseau. Vous devez avoir des méthodes claires pour signaler aux
- applications et aux utilisateurs les bases de données à utiliser. En
- l'absence de telles méthodes, la réplication ne fera qu'empirer le potentiel
- de confusion, et les bascules d'urgence seront un énorme potentiel de
- confusion.
- </para>
-</warning>
-
-<para>
- Si la base de données est très volumineuse, la construction du nœud 1
- peut prendre plusieurs heures ; ceci est une autre raison de considérer
- les bascules d'urgence comme un <quote>dernier recours</quote> non
- souhaitable.
-</para>
-
-</sect2>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/failover.xml (from rev 1244, traduc/trunk/slony/failover.xml)
===================================================================
--- traduc/tags/slony_1_2_12/failover.xml (rev 0)
+++ traduc/tags/slony_1_2_12/failover.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,366 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="failover">
+<title>Effectuer une bascule d'urgence avec &slony1;</title>
+<indexterm>
+ <primary>bascule d'urgence</primary>
+ <secondary>reprise sur panne</secondary>
+</indexterm>
+
+<sect2>
+<title>Avant-propos</title>
+
+<para>
+ &slony1; est un système de réplication asynchrone. À cause de cela, il est
+ presque certain qu'au moment où le nœud origine d'un ensemble de
+ réplication tombe en panne, la dernière transaction <quote>validée</quote>
+ sur l'origine ne soit pas encore propagée aux abonnés. Les systèmes qui
+ tombent en panne sont souvent soumis à une forte charge ; c'est un
+ des corollaires de la loi de Murphy. Ainsi le but principal est
+ d'<emphasis>éviter</emphasis> que le serveur principal tombe en panne. La
+ meilleure façon d'éviter cela est d'effectuer une maintenance fréquente.
+</para>
+
+<para>
+ Ouvrir le capot d'un serveur à chaud n'est pas ce qu'on peut appeler une
+ façon <quote>professionelle</quote> d'assurer la maintenance d'un système.
+ En général, les utilisateurs qui ont besoin de réplication pour leur
+ sauvegarde ou leur plan de reprise sur panne, ont également des critères
+ très stricts en matière de <quote>temps d'arrêt du système</quote>. Pour
+ répondre à ces critères, &slony1; ne se contente pas de fournir des méthodes
+ de reprise sur panne, il intègre également la notion de transfert d'origine.
+</para>
+
+<para>
+ On suppose dans cette partie que le lecteur est familier avec l'utilitaire
+ <xref linkend="slonik"/> et qu'il sait comment mettre en place un système de
+ réplication &slony1; composé de deux nœuds.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Bascule contrôlée</title>
+<indexterm><primary>bascule contrôlée</primary></indexterm>
+
+<para>
+ Imaginons un nœud <quote>origine</quote>, appelé nœud1, avec un
+ <quote>abonné</quote> appelé nœud2 (l'esclave). Une application web,
+ placée sur un troisième serveur, accède à la base de données sur nœud1.
+ Les deux bases sont actives et fonctionnelles, la réplication est est à peu
+ près synchronisée. On contrôle la bascule avec la commande <xref
+ linkend="stmtmoveset"/>.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Au moment ou nous écrivons ces lignes, basculer vers un autre serveur
+ nécessite que l'application se reconnecte à la base de donnée.
+ Donc, pour éviter toute complication, nous éteignons le serveur web. Les
+ utilisateurs qui ont installé <application>pgpool</application> pour
+ gérer les connexions peuvent simplement éteindre le pool.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Un petit script <xref linkend="slonik"/> exécute les commandes
+ suivantes :
+
+ <programlisting>lock set (id = 1, origin = 1);
+wait for event (origin = 1, confirmed = 2);
+move set (id = 1, old origin = 1, new origin = 2);
+wait for event (origin = 1, confirmed = 2);</programlisting>
+ </para>
+
+ <para>
+ Après ces commandes, l'origine (rôle du maître) de l'ensemble de
+ réplication 1 est transféré sur le nœud 2. En fait, elle n'est
+ pas simplement transférée ; le nœud1 devient un abonné
+ parfaitement synchronisé et actif. Autrement dit, les deux nœuds
+ ont échangé leurs rôles respectifs.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Après la reconfiguration de l'application web (ou de
+ <application><link linkend="pgpool">pgpool</link></application>) pour
+ qu'elle se connecte à la base du nœud 2, le serveur web est
+ redémarré et reprend son activité normale.
+ </para>
+
+ <para>
+ Lorsqu'on utilise un script shell, pour stopper l'application, lancer le
+ script <application>slonik</application>, déplacer les fichiers de
+ configuration et relancer l'ensemble, toute la procédure prend en général
+ moins de 10 secondes.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Vous pouvez désormais éteindre le serveur qui héberge le nœud 1 et
+ effectuer les opérations de maintenance requise. Lorsque le démon <xref
+ linkend="slon"/> du nœud 1 est redémarré, il reprend la réplication,
+ et rattrape son retard. Une fois synchronisé, on peut exécuter la procédure
+ à nouveau pour restaurer la configuration originale.
+</para>
+
+<para>
+ Ceci est la meilleure méthode pour ce genre d'opération de maintenance ;
+ elle s'effectue rapidement, sous le contrôle d'un administrateur, et elle
+ n'implique aucune perte de données.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Bascule d'urgence</title>
+<indexterm><primary>bascule suite à une panne du système</primary></indexterm>
+
+<para>
+ Lorsque de graves problèmes apparaissent sur le serveur <quote>origine</quote>,
+ il est parfois nécessaire d'effectuer une bascule (<xref
+ linkend="stmtfailover"/>) vers le serveur de sauvegarde. Ce cas de figure n'a
+ rien de souhaitable car les transactions <quote>validées</quote> sur le
+ serveur mais pas sur les abonnés, seront perdues. Certaines de ces
+ transactions auront peut-être été annoncées à l'utilisateur final comme
+ <quote>validées</quote>. En conséquence, les bascules d'urgence doivent être
+ considérées comme un <emphasis>dernier recours</emphasis>. Si le serveur
+ origine qui subit <quote>l'avarie</quote> peut être maintenu assez longtemps,
+ il est <emphasis>nettement</emphasis> préférable d'effectuer une bascule
+ contrôlée.
+</para>
+
+<para>
+ &slony1; ne fournit pas de moyen pour détecter les pannes du système.
+ Abandonner des transactions <quote>validées</quote> est une décision
+ commerciale qui ne peut pas être prise par un système de gestion de base de
+ données. Si vous voulez placer les commandes ci-dessous dans un script exécuté
+ automatiquement par un système de surveillance, ce sont
+ <emphasis>vos</emphasis> données, et <emphasis>votre</emphasis> politique de
+ bascule d'urgence.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ La commande <xref linkend="slonik"/>
+ <programlisting>failover (id = 1, backup node = 2);</programlisting>
+ ordonne au nœud 2 de se considérer comme le propriétaire
+ (l'origine) de tous les ensembles que le nœud 1 possédait. S'il
+ existe des nœuds supplémentaires dans le cluster &slony1;, tous
+ les nœuds abonnés au nœud 1 sont avertis du changement.
+ <application>Slonik</application> va aussi envoyer une requête
+ à chaque abonné pour déterminer le nœud de plus haut niveau de
+ synchronisation (<emphasis>c'est-à-dire</emphasis> la dernière
+ transaction <quote>validée</quote>) pour chaque ensemble de réplication.
+ La configuration sera changée de façon à ce que le nœud 2 applique
+ d'abord ces transactions finales, avant d'autoriser l'accès en écriture
+ sur les tables.
+ </para>
+
+ <para>
+ De plus, tous les nœuds qui étaient abonnés directement au nœud
+ 1 considèreront désormais le nœud 2 comme leur fournisseur de données
+ pour cet ensemble de replication. Cela signifie qu'une fois que la commande
+ de bascule d'urgence est complétée, plus aucun nœud du cluster ne
+ reçoit d'information de la part du nœud 1.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Reconfigurer et relancer l'application (ou
+ <application>pgpool</application>) pour qu'elle se reconnecte
+ au nœud 2.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Purger le nœud abandonné.</para>
+
+ <para>
+ Vous découvrirez, après la bascule, qu'il existe encore beaucoup de
+ références au nœud 1 dans la table <xref linkend="table.sl-node"/>,
+ ainsi que ses tables associées telle que <xref
+ linkend="table.sl-confirm"/> ; puisque des données sont toujours
+ présentes dans <xref linkend="table.sl-log-1"/>, &slony1; ne peut pas
+ purger immédiatement le nœud.
+ </para>
+
+ <para>
+ Une fois que la bascule est complète et que le nœud 2 accepte
+ les opérations d'écriture sur les tables répliquées, il faut supprimer
+ toutes les informations de configuration rémanentes avec la commande
+ <xref linkend="stmtdropnode"/> :
+
+ <programlisting>drop node (id = 1, event node = 2);</programlisting>
+ </para>
+
+ <para>
+ Supposons que la panne résulte d'un problème matériel catastrophique sur
+ le nœud 1, il est possible qu'il ne <quote>reste</quote> plus rien
+ sur le nœud 1. Si la panne n'est pas <quote>totale</quote>, ce qui
+ est souvent le cas lors d'une coupure réseau, vous découvrirez que le
+ nœud 1 <quote>imagine</quote> toujours que rien n'a changé et qu'il
+ est dans le même état qu'avant la panne. Reportez-vous à la section <xref
+ linkend="rebuildnode1"/> pour plus de détails sur ce que cela implique.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2>
+<title>Automatisation de la commande <command>FAIL OVER</command></title>
+<indexterm><primary>automatisation des bascules d'urgence</primary></indexterm>
+
+<para>
+ Si vous choisissez d'automatiser la commande <command>FAIL OVER </command>,
+ il est important de le faire <emphasis>avec soin</emphasis>. Vous devez être
+ sur que le nœud en panne est réellement en panne, et vous devez être
+ capable de vous assurer que le nœud en panne ne redémarre pas, ce qui
+ entraînerait un conflit entre deux nœuds capables de jouer le rôle du
+ <quote>maître</quote>.
+</para>
+
+<note>
+ <para>
+ Le fait de <quote>tirer une balle dans la tête du serveur en panne</quote>
+ ne pose pas directement de problème à la réplication ou à &slony1; ;
+ &slony1; supporte cela de manière assez tranquillement car, une fois qu'un
+ nœud est marqué comme étant en panne, les autres nœuds
+ <quote>l'oublient</quote> et l'ignorent. Le problème se situe plutôt au
+ niveau de <emphasis>votre application</emphasis>. Supposons que le
+ nœud en panne soit capable de répondre aux requêtes de votre
+ application, <emphasis>cela</emphasis> va certainement poser un problème
+ qui n'a rien à voir avec &slony1;. Le problème est que deux bases de
+ données sont en mesure de répondre en tant que <quote>maître</quote>.
+ </para>
+</note>
+
+<para>
+ Lorsqu'une bascule d'urgence est effectuée, il faut un mécanisme pour dégager
+ de force le nœud en panne hors du réseau afin d'éviter toute confusion
+ au niveau des applications. Cela peut être fait via une interface SNMP qui
+ effectue une partie des opérations suivantes :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>Éteindre l'alimentation du serveur en panne.</para>
+
+ <para>
+ Si l'on ne fait pas attention, le serveur peut réapparaître dans le
+ système de réplication si un administrateur le rallume.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Modifier les règles du pare-feu ou d'autres configurations pour exclure
+ du réseau l'adresse IP du serveur en panne.
+ </para>
+
+ <para>
+ Si le serveur a de multiples interfaces, et donc de multiple adresses IP,
+ cette approche permet de supprimer/désactiver les adresses utilisées
+ par l'application, tout en conservant les adresses
+ <quote>administratives</quote> afin que le serveur reste accessible par
+ les administrateurs systèmes.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2 id="rebuildnode1">
+<title>Après la bascule d'urgence, reconfiguration de l'ancienne origine</title>
+<indexterm><primary>reconstruction après une bascule d'urgence</primary></indexterm>
+
+<para>
+ Ce qui arrive au nœud en panne dépend beaucoup de la nature de la
+ catastrophe qui a conduit à la bascule d'urgence vers un autre nœud.
+ Si le nœud a été abandonné à cause de la destruction physique des
+ disques de stockage, il n'y a plus grand-chose à faire. D'un autre coté,
+ si un nœud a été abandonné à cause d'une coupure réseau, qui n'a pas
+ perturbé le fonctionnement normal du nœud <quote>fournisseur</quote>.
+ Toutefois, une fois que les communications sont restaurées, le fait est que
+ la commande <command>FAIL OVER</command> rend obligatoire l'abandon du
+ nœud qui était en panne.
+</para>
+
+<para>
+ Après ce genre de bascule d'urgence, les données stockées sur le nœud 1
+ seront rapidement et de plus en plus désynchronisées par rapport aux autres
+ nœuds. Elles doivent être considérées comme corrompues. Ainsi le seul
+ moyen pour que le nœud 1 retourne dans le cluster de réplication et
+ qu'il redevienne le nœud origine est de le reconstruire à partir de
+ zéro comme un abonné, de le laisser rattraper son retard, puis d'effectuer
+ la procédure de bascule contrôlée.
+</para>
+
+<para>
+ Une bonne raison de <emphasis>ne pas</emphasis> faire cela automatiquement
+ est que d'importantes mises à jour (d'un point de vue
+ <emphasis>commercial</emphasis>) ont pu être <quote>validées</quote> sur le
+ système en panne. Vous souhaiterez probablement analyser les dernières
+ transactions que le nœud a réalisé avant de tomber en panne, afin de
+ voir si certaines doivent être ré-appliquer sur le cluster
+ <quote>actif</quote>. Par exemple, si quelqu'un réalisait des opérations
+ bancaires impactant des comptes clients au moment de la panne, il est
+ souhaitable de ne pas perdre cette information.
+</para>
+
+<warning>
+ <para>
+ On a observé certains résultats étranges lorsqu'un nœud <quote>tombe
+ en panne</quote> à cause d'une coupure réseau persistante, par opposition
+ aux pannes du système de stockage. Dans de tels scénarios, le nœud
+ <quote>en panne</quote> dispose d'une base de données en parfait état de
+ marche ; le fait est qu'ayant été coupé des autres nœuds, il
+ <quote>crie en silence</quote>.
+ </para>
+
+ <para>
+ Lorsque la connexion réseau est réparée, ce nœud peut réapparaître et
+ conformément à <emphasis>sa</emphasis> configuration, il va communiquer
+ avec les autres nœuds du cluster &slony1;.
+ </para>
+
+ <para>
+ En <emphasis>fait</emphasis>, la confusion se trouve uniquement sur ce
+ nœud. Les autres nœud du cluster ne sont pas du tout
+ perturbés ; ils savent que ce nœud est <quote>mort</quote> et
+ qu'ils doivent l'ignorer. Mais il est impossible de savoir cela en
+ regardant le nœud qui était <quote>en panne</quote>.
+ </para>
+
+ <para>
+ Ceci nous ramène au fait que &slony1; n'est pas un outil de surveillance de
+ réseau. Vous devez avoir des méthodes claires pour signaler aux
+ applications et aux utilisateurs les bases de données à utiliser. En
+ l'absence de telles méthodes, la réplication ne fera qu'empirer le potentiel
+ de confusion, et les bascules d'urgence seront un énorme potentiel de
+ confusion.
+ </para>
+</warning>
+
+<para>
+ Si la base de données est très volumineuse, la construction du nœud 1
+ peut prendre plusieurs heures ; ceci est une autre raison de considérer
+ les bascules d'urgence comme un <quote>dernier recours</quote> non
+ souhaitable.
+</para>
+
+</sect2>
+
+</sect1>
Deleted: traduc/tags/slony_1_2_12/filelist.xml
===================================================================
--- traduc/trunk/slony/filelist.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/filelist.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,69 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<!ENTITY intro SYSTEM "intro.xml">
-<!ENTITY prerequisites SYSTEM "prerequisites.xml">
-<!ENTITY installation SYSTEM "installation.xml">
-<!ENTITY slonik SYSTEM "slonik.xml">
-<!ENTITY concepts SYSTEM "concepts.xml">
-<!ENTITY cluster SYSTEM "cluster.xml">
-<!ENTITY defineset SYSTEM "defineset.xml">
-<!ENTITY adminscripts SYSTEM "adminscripts.xml">
-<!ENTITY startslons SYSTEM "startslons.xml">
-<!ENTITY subscribenodes SYSTEM "subscribenodes.xml">
-<!ENTITY monitoring SYSTEM "monitoring.xml">
-<!ENTITY maintenance SYSTEM "maintenance.xml">
-<!ENTITY reshape SYSTEM "reshape.xml">
-<!ENTITY failover SYSTEM "failover.xml">
-<!ENTITY listenpaths SYSTEM "listenpaths.xml">
-<!ENTITY plainpaths SYSTEM "plainpaths.xml">
-<!ENTITY addthings SYSTEM "addthings.xml">
-<!ENTITY dropthings SYSTEM "dropthings.xml">
-<!ENTITY ddlchanges SYSTEM "ddlchanges.xml">
-<!ENTITY firstdb SYSTEM "firstdb.xml">
-<!ENTITY help SYSTEM "help.xml">
-<!ENTITY faq SYSTEM "faq.xml">
-<!ENTITY reference SYSTEM "reference.xml">
-<!ENTITY slonik SYSTEM "slonik.xml">
-<!ENTITY usingslonik SYSTEM "usingslonik.xml">
-<!ENTITY versionupgrade SYSTEM "versionupgrade.xml">
-<!ENTITY slonikref SYSTEM "slonik_ref.xml">
-<!ENTITY slon SYSTEM "slon.xml">
-<!ENTITY slonconf SYSTEM "slonconf.xml">
-<!ENTITY schemadoc SYSTEM "schemadoc.xml">
-
-<!ENTITY history SYSTEM "history.xml">
-<!ENTITY legal SYSTEM "legal.xml">
-<!ENTITY notation SYSTEM "notation.xml">
-<!ENTITY problems SYSTEM "problems.xml">
-<!ENTITY slonybook SYSTEM "slony.xml">
-<!ENTITY logshipfile SYSTEM "logshipping.xml">
-<!ENTITY bestpractices SYSTEM "bestpractices.xml">
-<!ENTITY locking SYSTEM "locking.xml">
-<!ENTITY supportedplatforms SYSTEM "supportedplatforms.xml">
-<!ENTITY testbed SYSTEM "testbed.xml">
-<!ENTITY loganalysis SYSTEM "loganalysis.xml">
-<!ENTITY slonyupgrade SYSTEM "slonyupgrade.xml">
-<!ENTITY releasechecklist SYSTEM "releasechecklist.xml">
-<!ENTITY raceconditions SYSTEM "raceconditions.xml">
-<!ENTITY partitioning SYSTEM "partitioning.xml">
-<!ENTITY triggers SYSTEM "triggers.xml">
-
-<!-- specifique PGFR -->
-<!ENTITY frenchtranslation SYSTEM "frenchtranslation.xml">
-
-<!-- back matter -->
-<!ENTITY biblio SYSTEM "biblio.xml">
-<!ENTITY bookindex SYSTEM "bookindex.xml">
-
-<!--
- Some parts of the documentation are also source for some plain-text
- files used during installation. To selectively ignore or include
- some parts (e.g., external xref's) when generating these files we use
- these parameter entities. See also standalone-install.xml.
- -->
-<!ENTITY % standalone-ignore "INCLUDE">
-<!ENTITY % standalone-include "IGNORE">
Copied: traduc/tags/slony_1_2_12/filelist.xml (from rev 1244, traduc/trunk/slony/filelist.xml)
===================================================================
--- traduc/tags/slony_1_2_12/filelist.xml (rev 0)
+++ traduc/tags/slony_1_2_12/filelist.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<!ENTITY intro SYSTEM "intro.xml">
+<!ENTITY prerequisites SYSTEM "prerequisites.xml">
+<!ENTITY installation SYSTEM "installation.xml">
+<!ENTITY slonik SYSTEM "slonik.xml">
+<!ENTITY concepts SYSTEM "concepts.xml">
+<!ENTITY cluster SYSTEM "cluster.xml">
+<!ENTITY defineset SYSTEM "defineset.xml">
+<!ENTITY adminscripts SYSTEM "adminscripts.xml">
+<!ENTITY startslons SYSTEM "startslons.xml">
+<!ENTITY subscribenodes SYSTEM "subscribenodes.xml">
+<!ENTITY monitoring SYSTEM "monitoring.xml">
+<!ENTITY maintenance SYSTEM "maintenance.xml">
+<!ENTITY reshape SYSTEM "reshape.xml">
+<!ENTITY failover SYSTEM "failover.xml">
+<!ENTITY listenpaths SYSTEM "listenpaths.xml">
+<!ENTITY plainpaths SYSTEM "plainpaths.xml">
+<!ENTITY addthings SYSTEM "addthings.xml">
+<!ENTITY dropthings SYSTEM "dropthings.xml">
+<!ENTITY ddlchanges SYSTEM "ddlchanges.xml">
+<!ENTITY firstdb SYSTEM "firstdb.xml">
+<!ENTITY help SYSTEM "help.xml">
+<!ENTITY faq SYSTEM "faq.xml">
+<!ENTITY reference SYSTEM "reference.xml">
+<!ENTITY slonik SYSTEM "slonik.xml">
+<!ENTITY usingslonik SYSTEM "usingslonik.xml">
+<!ENTITY versionupgrade SYSTEM "versionupgrade.xml">
+<!ENTITY slonikref SYSTEM "slonik_ref.xml">
+<!ENTITY slon SYSTEM "slon.xml">
+<!ENTITY slonconf SYSTEM "slonconf.xml">
+<!ENTITY schemadoc SYSTEM "schemadoc.xml">
+
+<!ENTITY history SYSTEM "history.xml">
+<!ENTITY legal SYSTEM "legal.xml">
+<!ENTITY notation SYSTEM "notation.xml">
+<!ENTITY problems SYSTEM "problems.xml">
+<!ENTITY slonybook SYSTEM "slony.xml">
+<!ENTITY logshipfile SYSTEM "logshipping.xml">
+<!ENTITY bestpractices SYSTEM "bestpractices.xml">
+<!ENTITY locking SYSTEM "locking.xml">
+<!ENTITY supportedplatforms SYSTEM "supportedplatforms.xml">
+<!ENTITY testbed SYSTEM "testbed.xml">
+<!ENTITY loganalysis SYSTEM "loganalysis.xml">
+<!ENTITY slonyupgrade SYSTEM "slonyupgrade.xml">
+<!ENTITY releasechecklist SYSTEM "releasechecklist.xml">
+<!ENTITY partitioning SYSTEM "partitioning.xml">
+
+<!-- specifique PGFR -->
+<!ENTITY frenchtranslation SYSTEM "frenchtranslation.xml">
+
+<!-- back matter -->
+<!ENTITY biblio SYSTEM "biblio.xml">
+<!ENTITY bookindex SYSTEM "bookindex.xml">
+
+<!--
+ Some parts of the documentation are also source for some plain-text
+ files used during installation. To selectively ignore or include
+ some parts (e.g., external xref's) when generating these files we use
+ these parameter entities. See also standalone-install.xml.
+ -->
+<!ENTITY % standalone-ignore "INCLUDE">
+<!ENTITY % standalone-include "IGNORE">
Deleted: traduc/tags/slony_1_2_12/firstdb.xml
===================================================================
--- traduc/trunk/slony/firstdb.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/firstdb.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,456 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="firstdb">
-<title>Répliquer votre première base de données</title>
-<indexterm><primary>répliquer votre première base de données</primary></indexterm>
-
-<para>
- Dans cet exemple, nous allons répliquer une base de données
- <application>pgbench</application> neuve. Les mécanismes de réplications
- d'une base existante sont abordés ici, cependant nous vous recommandons
- d'apprendre comment utiliser les fonctions &slony1; en utilisant une base
- fraîchement créée, placée sur un serveur qui n'est pas en production.
-</para>
-
-<para>
- Notez que <application>pgbench</application> est un outil de
- <quote>tests</quote> (« benchmark ») qui se trouve parmi les outils
- <filename>contrib</filename> de &postgres; Si vous compilez &postgres; depuis
- les sources, vous devez vous rendre dans le répertoire
- <filename>contrib/pgbench</filename> et exécuter la commande <command>make
- install</command> pour le compiler et l'installer ; vous pouvez par
- ailleurs le trouver inclus dans les paquets binaires de &postgres;.
-</para>
-
-<para>
- Le moteur de réplication de &slony1; est basé sur les triggers, ce qui permet
- de répliquer des bases de données (ou des parties de celles-ci) hébergées par
- le même postmaster.</para>
-
-<para>
- Cet exemple montre comment répliquer la base <application>pgbench</application>
- hébergée sur localhost (maître) vers la base <application>pgbench</application>
- esclave hébergée elle-aussi sur localhost (esclave). Nous nous basons sur deux
- suppositions à propos de votre configuration de &postgres; :
-
- <itemizedlist>
- <listitem>
- <para>
- Vous avez la ligne <option>tcpip_socket=true</option> dans votre
- <filename>postgresql.conf</filename> et
- </para>
- </listitem>
-
- <listitem>
- <para>
- Vous avez activé les accès à votre cluster via
- <filename>pg_hba.conf</filename>.
- </para>
- </listitem>
- </itemizedlist>
-</para>
-
-<para>
- L'utilisateur <envar>REPLICATIONUSER</envar> doit être un super-utilisateur
- &postgres;. C'est en général postgres ou pgsql. Cependant, au sein
- d'environnements complexes, il est parfois judicieux de définir un utilisateur
- <command>slony</command> pour distinguer les différents rôles.
-</para>
-
-<para>
- Vous devez également définir les variables shell suivantes :
-
- <itemizedlist>
- <listitem><para><envar>CLUSTERNAME</envar>=exemple_slony</para></listitem>
- <listitem><para><envar>MASTERDBNAME</envar>=pgbench</para></listitem>
- <listitem><para><envar>SLAVEDBNAME</envar>=pgbench_esclave</para></listitem>
- <listitem><para><envar>MASTERHOST</envar>=localhost</para></listitem>
- <listitem><para><envar>SLAVEHOST</envar>=localhost</para></listitem>
- <listitem><para><envar>REPLICATIONUSER</envar>=pgsql</para></listitem>
- <listitem><para><envar>PGBENCHUSER</envar>=pgbench</para></listitem>
- </itemizedlist>
-</para>
-
-<para>
- Voici deux manières de paramétrer ces variables avec un shell standard :
-
- <itemizedlist>
- <listitem>
- <para>
- bash, sh, ksh :
- <command>export CLUSTERNAME=exemple_slony</command>
- </para>
- </listitem>
-
- <listitem>
- <para>
- (t)csh :
- <command>setenv CLUSTERNAME exemple_slony</command>
- </para>
- </listitem>
- </itemizedlist>
-</para>
-
-<para>
- <warning>
- <para>
- Si vous changez vos variables afin d'utiliser différents hôtes pour
- <envar>MASTERHOST</envar> et <envar>SLAVEHOST</envar>, soyez certain de
- <emphasis>ne pas</emphasis> utiliser localhost pour aucun des deux. Ceci
- provoquerait une erreur similaire à celle-ci :
- </para>
-
- <para>
- <command>ERROR remoteListenThread_1: db_getLocalNodeId() returned 2 -
- wrong database?</command>
- </para>
- </warning>
-</para>
-
-<sect2>
-<title>Créer l'utilisateur <application>pgbench</application></title>
-
-<para>
- <command>createuser -A -D $PGBENCHUSER</command>
-</para>
-
-</sect2>
-
-<sect2><title>Préparer les bases</title>
-
-<programlisting>createdb -O $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME
-createdb -O $PGBENCHUSER -h $SLAVEHOST $SLAVEDBNAME
-pgbench -i -s 1 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME</programlisting>
-
-<para>
- Une des tables créées par <application>pgbench</application>,
- <envar>history</envar>, n'a pas de clé primaire. Dans les versions
- antérieures de &slony1;, une commande &slonik; nommée <xref
- linkend="stmttableaddkey"/> pouvait être utilisées pour en introduire une.
- Ceci provoquait de nombreux problèmes si bien que cette fonctionnalité fut
- supprimée dans la version 2 de &slony1;. Il est désormais
- <emphasis>nécessaire</emphasis> d'avoir une ensemble éligible en tant que
- clé primaire.
-</para>
-
-<para>
- Les requêtes SQL suivantes établissent une clé primaire cohérente pour cette
- table :
-</para>
-
-<programlisting>psql -U $PGBENCH_USER -h $HOST1 -d $DBNAME1 -c "begin; alter table
-history add column id serial; update history set id =
-nextval('history_id_seq'); alter table history add primary key(id);
-commit"</programlisting>
-
-<para>
- Puisque &slony1; dépend de la présence du langage procédural pl/pgSQL, nous
- devons l'installer maintenant. Il est possible que vous ayez installé
- pl/pgSQL dans la base template1, auquel cas vous pouvez sauter cette étape
- car le langage est installé par défaut dans la base
- <envar>$MASTERDBNAME</envar>.
-
- <programlisting>createlang -h $MASTERHOST plpgsql $MASTERDBNAME</programlisting>
-</para>
-
-<para>
- &slony1; ne copie pas automatiquement les définitions de tables du maître
- lorsqu'un esclave s'y connecte, ainsi nous devons importer ces données. Nous
- réalisons cette opération avec <application>pg_dump</application>.
-
- <programlisting>pg_dump -s -U $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME
- | psql -U $REPLICATIONUSER -h $SLAVEHOST $SLAVEDBNAME</programlisting>
-</para>
-
-<para>
- Pour illustrer comment &slony1; permet une réplication à la volée, nous
- lançons l'application <application>pgbench</application>. Si vous exécutez
- <application>pgbench</application> en tâche de premier plan dans une fenêtre
- de terminal séparée, vous pouvez l'arrêter et le relancer à tout moment avec
- des paramètres différents. Vous devrez exporter les variables d'environnement
- pour qu'elles soient également disponibles dans cette session.
-</para>
-
-<para>
- La commande habituelle pour exécuter <application>pgbench</application>
- est :
-
- <programlisting>pgbench -s 1 -c 5 -t 1000 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME</programlisting>
-</para>
-
-<para>
- Ceci lancera <application>pgbench</application> avec cinq clients concurrents,
- exécutant chacun 1000 transactions sur la base <application>pgbench</application>
- hébergées sur localhost, en utilisant l'utilisateur pgbench.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Configurer la base de donnée pour la réplication</title>
-
-<para>
- La création des tables de configuration, des procédures stockées, des triggers
- et la configuration sont prises en charges par l'outil <xref
- linkend="slonik"/>. Il s'agit d'un script d'aide spécialisé qui appelle
- principalement des procédures stockées sur les nœuds maître et esclaves.
-</para>
-
-<sect3><title>Utiliser les scripts altperl</title>
-<indexterm><primary>Utilisation des scripts altperl</primary></indexterm>
-
-<para>
- L'utilisation des scripts <xref linkend="altperl"/> est une façon simple de
- faire ses premiers pas. Le script <command>slonik_build_env</command> génère
- une sortie fournissant les détails nécessaires à la construction complète
- d'un fichier <filename>rslon_tools.conf</filename>. Un exemple de fichier
- <filename>slon_tools.conf</filename> est fournit dans la distribution afin
- d'aider à la prise en main. Les script altperl font tous référence à ce
- fichier central de configuration afin de simplifier l'administration. Une
- fois le fichier slon_tools.conf créé, vous pouvez poursuivre comme ceci :
-</para>
-
-<programlisting># Initialisation du cluster:
-$ slonik_init_cluster | slonik
-
-# Démarrage de slon (ici 1 et 2 sont les numéros de nœuds)
-$ slon_start 1
-$ slon_start 2
-
-# Création des ensemble (ici 1 est le numéro de l'ensemble)
-$ slonik_create_set 1
-
-# Abonner l'ensemble dans le second nœud (1= n° d'ensemble, 2= n° de nœud)
-$ slonik_subscribe_set 1 2 | slonik</programlisting>
-
-<para>
- Vous avez répliqué votre première base de données. Vous pouvez sauter la
- section suivante de la documentation si vous le souhaitez car il s'agit
- d'une approche plus <quote>rustre</quote>.
-</para>
-
-</sect3>
-
-<sect3>
-<title>Utiliser directement les commandes slonik</title>
-
-<para>
- L'approche traditionnelle pour administrer slony consiste à utiliser
- directement les commandes slonik. En voici un exemple.
-</para>
-
-<para>
- Le script de création de la configuration initiale pour une simple
- configuration maître-esclave de la base <application>pgbench</application>
- est le suivant :
-</para>
-
-<programlisting><![CDATA[
-#!/bin/sh
-
-slonik <<_EOF_
- #--
- # définition de l'espace de nom du système de réplication
- # dans notre exemple, il s'agit de exemple_slony
- #--
- cluster name = $CLUSTERNAME;
-
- #--
- # les paramètres "admin conninfo" sont utilisé par slonik pour se
- # connecter aux noeuds. Une ligne par noeud. La syntaxe est celle de
- # PQconnectdb de l'API C
- # --
- node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER';
- node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST user=$REPLICATIONUSER';
-
- #--
- # initialisation du premier noeud. Son identifiant DOIT être 1. Cela
- # provoque la création du schéma _$CLUSTERNAME contenant tous les objets
- # spécifiques du système de réplication
- #--
- init cluster ( id=1, comment = 'Master Node');
-
- #--
- # Puisque la table history n'a pas de clé primaire, ni de contrainte
- # unique qui pourrait être utilisée pour identifier une ligne, nous
- # devons en ajouter une.
- # La commande suivante ajoute à la table une colonne bigint nommée
- # _Slony-I_$CLUSTERNAME_rowID. Elle comme valeur par défaut
- # nextval('_$CLUSTERNAME.s1_rowid_seq'), et dispose des contraintes
- # UNIQUE et NOT NULL. Toutes les lignes existantes seront initialisées
- # avec un dentifiant.
- #--
- table add key (node id = 1, fully qualified name = 'public.history');
-
- #--
- # Slony-I regroupe les tables dans des ensembles.
- # La plus petite unité qu'un noeud peut répliquer est un ensemble.
- # Les commandes suivantes crées un ensemble contenant 4 tables pgbench.
- # Le maître (ou origine) de l'ensemble est le noeud 1.
- #--
- create set (id=1, origin=1, comment='All pgbench tables');
- set add table (set id=1, origin=1, id=1, fully qualified name = 'public.accounts', comment='accounts table');
- set add table (set id=1, origin=1, id=2, fully qualified name = 'public.branches', comment='branches table');
- set add table (set id=1, origin=1, id=3, fully qualified name = 'public.tellers', comment='tellers table');
- set add table (set id=1, origin=1, id=4, fully qualified name = 'public.history', comment='history table');
-
- #--
- # Création du second noeud (l'esclave)
- # décrit comment les 2 noeuds vont se connecter l'un à l'autre
- # et quelle manière ils vont écouter les événements..
- #--
- store node (id=2, comment = 'Slave node');
- store path (server = 1, client = 2, conninfo='dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER');
- store path (server = 2, client = 1, conninfo='dbname=$SLAVEDBNAME host=$SLAVEHOST user=$REPLICATIONUSER');
-_EOF_
-]]></programlisting>
-
-<para>
- L'application <application>pgbench</application> est-elle toujours
- exécutée ? Si ce n'est pas le cas, redémarrez-la.
-</para>
-
-<para>
- À ce moment, nous avons deux bases de données qui sont complètement préparées.
- L'une d'elle est la base maître, celle que l'application
- <application>pgbench</application> utilise pour lire et modifier des lignes.
- Le temps est donc venu de lancer les démons de réplication.
-</para>
-
-<para>
- Sur $MASTERHOST, la commande pour démarrer le moteur de réplication est :
-
- <programlisting>slon $CLUSTERNAME "dbname=$MASTERDBNAME user=$REPLICATIONUSER host=$MASTERHOST"</programlisting>
-</para>
-
-<para>
- De la même façon, nous démarrons le système de réplication sur le nœud 2
- (l'esclave) :
-
- <programlisting>slon $CLUSTERNAME "dbname=$SLAVEDBNAME user=$REPLICATIONUSER host=$SLAVEHOST"</programlisting>
-</para>
-
-<para>
- Même si nous avons désormais le démon <xref linkend="slon"/> exécuté à la fois
- sur le maître et l'esclave, et qu'ils sont tous les deux en train de cracher
- des diagnostiques et d'autres messages, les données ne sont toujours pas
- répliquées. L'activité que vous constatez est la synchronisation de la
- configuration du cluster entre les deux processus <xref linkend="slon"/>.
-</para>
-
-<para>
- Pour démarrer la réplication des quatre tables <application>pgbench</application>
- (l'ensemble 1) depuis le maître (le nœud 1) vers l'esclave (le
- nœud 2), lancez le script suivant :
-
- <programlisting><![CDATA[
-#!/bin/sh
-slonik <<_EOF_
- # ----
- # Définition de l'espace de nom du cluster
- # ----
- cluster name = $CLUSTERNAME;
-
- # ----
- # Les paramètres conninfo sont utilisés par le programme slonik
- # pour se connecter aux noeuds. Ce sont donc les arguments
- # PQconnectdb pour se connecter depuis la station de travail
- # d'administration (où les scripts slonik sont exécutés).
- # ----
- node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER';
- node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST user=$REPLICATIONUSER';
-
- # ----
- # Le noeud 2 s'abonne à l'ensemble 1
- # ----
- subscribe set ( id = 1, provider = 1, receiver = 2, forward = no);
-_EOF_]]></programlisting>
-
-</para>
-
-<para>
- Désormais, le démon de réplication sur<envar>$SLAVEHOST</envar> se
- déclenchera à tout moment pour copier les changements d'états sur les quatre
- tables répliquées. Pendant ce temps, l'application
- <application>pgbench</application> va continuer à modifier la base de données.
- Lorsque le processus de copie est terminé, le démon de réplication sur le
- nœud <envar>$SLAVEHOST</envar> commencera à se synchroniser en
- appliquant les journaux de réplication qui auront été accumulés. Cela se
- fera par petit à petit, par tranches de 10 secondes de travail applicatifs.
- Selon les performances des deux systèmes impliqués, la taille des deux bases
- de données, la charge de transaction et la qualité de l'optimisation et de la
- maintenance effectuées sur les deux bases de données, ce processus de
- synchronisation peut durer quelques minutes, quelques heures ou quelques
- siècles.
-</para>
-
-<para>
- Vous avez maintenant configuré avec succès votre premier système de
- réplication maître-esclave basique, et les deux bases de données devraient,
- une fois que l'esclave sera synchronisé, contenir des données identiques. Ça,
- c'est la théorie, tout du moins. En pratique, il est bon de vérifier que les
- ensembles de données sont bien identiques.
-</para>
-
-<para>
- Le script ci-dessous crée des sauvegardes ordonnées des deux bases et les
- compare. Assurez-vous que le test <application>pgbench</application> est
- terminé, qu'il n'y pas d'autres mises à jour en cours sur le nœud
- origine, et que les sessions slon se sont synchronisées.
-</para>
-
-<programlisting><![CDATA[
-#!/bin/sh
-echo -n "**** comparing sample1 ... "
-psql -U $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME >dump.tmp.1.$$ <<_EOF_
- select 'accounts:'::text, aid, bid, abalance, filler
- from accounts order by aid;
- select 'branches:'::text, bid, bbalance, filler
- from branches order by bid;
- select 'tellers:'::text, tid, bid, tbalance, filler
- from tellers order by tid;
- select 'history:'::text, tid, bid, aid, delta, mtime, filler,
- "_Slony-I_${CLUSTERNAME}_rowID"
- from history order by "_Slony-I_${CLUSTERNAME}_rowID";
-_EOF_
-psql -U $REPLICATIONUSER -h $SLAVEHOST $SLAVEDBNAME >dump.tmp.2.$$ <<_EOF_
- select 'accounts:'::text, aid, bid, abalance, filler
- from accounts order by aid;
- select 'branches:'::text, bid, bbalance, filler
- from branches order by bid;
- select 'tellers:'::text, tid, bid, tbalance, filler
- from tellers order by tid;
- select 'history:'::text, tid, bid, aid, delta, mtime, filler,
- "_Slony-I_${CLUSTERNAME}_rowID"
- from history order by "_Slony-I_${CLUSTERNAME}_rowID";
-_EOF_
-
-if diff dump.tmp.1.$$ dump.tmp.2.$$ >$CLUSTERNAME.diff ; then
- echo "success - databases are equal."
- rm dump.tmp.?.$$
- rm $CLUSTERNAME.diff
-else
- echo "FAILED - see $CLUSTERNAME.diff for database differences"
-fi
-]]></programlisting>
-
-<para>
- Notez qu'il existe une documentation un peu plus sophistiquée concernant ce
- processus dans l'arborescence du code source de &slony1; au sein d'un fichier
- nommé <filename>slony-I-basic-mstr-slv.txt</filename>.
-</para>
-
-<para>
- Si ce script renvoie <command>FAILED</command>, merci de contacter les
- développeurs sur <ulink url="http://slony.info/">http://slony.info/</ulink>.
-</para>
-
-</sect3>
-
-</sect2>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/firstdb.xml (from rev 1244, traduc/trunk/slony/firstdb.xml)
===================================================================
--- traduc/tags/slony_1_2_12/firstdb.xml (rev 0)
+++ traduc/tags/slony_1_2_12/firstdb.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,435 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="firstdb">
+<title>Répliquer votre première base de données</title>
+<indexterm><primary>répliquer votre première base de données</primary></indexterm>
+
+<para>
+ Dans cet exemple, nous allons répliquer une base de données
+ <application>pgbench</application> neuve. Les mécanismes de réplications
+ d'une base existante sont abordés ici, cependant nous vous recommandons
+ d'apprendre comment utiliser les fonctions &slony1; en utilisant une base
+ fraîchement créée, placée sur un serveur qui n'est pas en production.
+</para>
+
+<para>
+ Notez que <application>pgbench</application> est un outil de
+ <quote>tests</quote> (« benchmark ») qui se trouve parmi les outils
+ <filename>contrib</filename> de &postgres; Si vous compilez &postgres; depuis
+ les sources, vous devez vous rendre dans le répertoire
+ <filename>contrib/pgbench</filename> et exécuter la commande <command>make
+ install</command> pour le compiler et l'installer ; vous pouvez par
+ ailleurs le trouver inclus dans les paquets binaires de &postgres;.
+</para>
+
+<para>
+ Le moteur de réplication de &slony1; est basé sur les triggers, ce qui permet
+ de répliquer des bases de données (ou des parties de celles-ci) hébergées par
+ le même postmaster.</para>
+
+<para>
+ Cet exemple montre comment répliquer la base <application>pgbench</application>
+ hébergée sur localhost (maître) vers la base <application>pgbench</application>
+ esclave hébergée elle-aussi sur localhost (esclave). Nous nous basons sur deux
+ suppositions à propos de votre configuration de &postgres; :
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Vous avez la ligne <option>tcpip_socket=true</option> dans votre
+ <filename>postgresql.conf</filename> et
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Vous avez activé les accès à votre cluster via
+ <filename>pg_hba.conf</filename>.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
+
+<para>
+ L'utilisateur <envar>REPLICATIONUSER</envar> doit être un super-utilisateur
+ &postgres;. C'est en général postgres ou pgsql. Cependant, au sein
+ d'environnements complexes, il est parfois judicieux de définir un utilisateur
+ <command>slony</command> pour distinguer les différents rôles.
+</para>
+
+<para>
+ Vous devez également définir les variables shell suivantes :
+
+ <itemizedlist>
+ <listitem><para><envar>CLUSTERNAME</envar>=exemple_slony</para></listitem>
+ <listitem><para><envar>MASTERDBNAME</envar>=pgbench</para></listitem>
+ <listitem><para><envar>SLAVEDBNAME</envar>=pgbench_esclave</para></listitem>
+ <listitem><para><envar>MASTERHOST</envar>=localhost</para></listitem>
+ <listitem><para><envar>SLAVEHOST</envar>=localhost</para></listitem>
+ <listitem><para><envar>REPLICATIONUSER</envar>=pgsql</para></listitem>
+ <listitem><para><envar>PGBENCHUSER</envar>=pgbench</para></listitem>
+ </itemizedlist>
+</para>
+
+<para>
+ Voici deux manières de paramétrer ces variables avec un shell standard :
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ bash, sh, ksh :
+ <command>export CLUSTERNAME=exemple_slony</command>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ (t)csh :
+ <command>setenv CLUSTERNAME exemple_slony</command>
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
+
+<para>
+ <warning>
+ <para>
+ Si vous changez vos variables afin d'utiliser différents hôtes pour
+ <envar>MASTERHOST</envar> et <envar>SLAVEHOST</envar>, soyez certain de
+ <emphasis>ne pas</emphasis> utiliser localhost pour aucun des deux. Ceci
+ provoquerait une erreur similaire à celle-ci :
+ </para>
+
+ <para>
+ <command>ERROR remoteListenThread_1: db_getLocalNodeId() returned 2 -
+ wrong database?</command>
+ </para>
+ </warning>
+</para>
+
+<sect2>
+<title>Créer l'utilisateur <application>pgbench</application></title>
+
+<para>
+ <command>createuser -A -D $PGBENCHUSER</command>
+</para>
+
+</sect2>
+
+<sect2><title>Préparer les bases</title>
+
+<programlisting>createdb -O $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME
+createdb -O $PGBENCHUSER -h $SLAVEHOST $SLAVEDBNAME
+pgbench -i -s 1 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME</programlisting>
+
+<para>
+ Puisque &slony1; dépend de la présence du langage procédural pl/pgSQL, nous
+ devons l'installer maintenant. Il est possible que vous ayez installé
+ pl/pgSQL dans la base template1, auquel cas vous pouvez sauter cette étape
+ car le langage est installé par défaut dans la base
+ <envar>$MASTERDBNAME</envar>.
+
+ <programlisting>createlang -h $MASTERHOST plpgsql $MASTERDBNAME</programlisting>
+</para>
+
+<para>
+ &slony1; ne copie pas automatiquement les définitions de tables du maître
+ lorsqu'un esclave s'y connecte, ainsi nous devons importer ces données. Nous
+ réalisons cette opération avec <application>pg_dump</application>.
+
+ <programlisting>pg_dump -s -U $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME
+ | psql -U $REPLICATIONUSER -h $SLAVEHOST $SLAVEDBNAME</programlisting>
+</para>
+
+<para>
+ Pour illustrer comment &slony1; permet une réplication à la volée, nous
+ lançons l'application <application>pgbench</application>. Si vous exécutez
+ <application>pgbench</application> en tâche de premier plan dans une fenêtre
+ de terminal séparée, vous pouvez l'arrêter et le relancer à tout moment avec
+ des paramètres différents. Vous devrez exporter les variables d'environnement
+ pour qu'elles soient également disponibles dans cette session.
+</para>
+
+<para>
+ La commande habituelle pour exécuter <application>pgbench</application>
+ est :
+
+ <programlisting>pgbench -s 1 -c 5 -t 1000 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME</programlisting>
+</para>
+
+<para>
+ Ceci lancera <application>pgbench</application> avec cinq clients concurrents,
+ exécutant chacun 1000 transactions sur la base <application>pgbench</application>
+ hébergées sur localhost, en utilisant l'utilisateur pgbench.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Configurer la base de donnée pour la réplication</title>
+
+<para>
+ La création des tables de configuration, des procédures stockées, des triggers
+ et la configuration sont prises en charges par l'outil <xref
+ linkend="slonik"/>. Il s'agit d'un script d'aide spécialisé qui appelle
+ principalement des procédures stockées sur les nœuds maître et esclaves.
+</para>
+
+<sect3><title>Utiliser les scripts altperl</title>
+<indexterm><primary>Utilisation des scripts altperl</primary></indexterm>
+
+<para>
+ L'utilisation des scripts <xref linkend="altperl"/> est une façon simple de
+ faire ses premiers pas. Le script <command>slonik_build_env</command> génère
+ une sortie fournissant les détails nécessaires à la construction complète
+ d'un fichier <filename>rslon_tools.conf</filename>. Un exemple de fichier
+ <filename>slon_tools.conf</filename> est fournit dans la distribution afin
+ d'aider à la prise en main. Les script altperl font tous référence à ce
+ fichier central de configuration afin de simplifier l'administration. Une
+ fois le fichier slon_tools.conf créé, vous pouvez poursuivre comme ceci :
+</para>
+
+<programlisting># Initialisation du cluster:
+$ slonik_init_cluster | slonik
+
+# Démarrage de slon (ici 1 et 2 sont les numéros de nœuds)
+$ slon_start 1
+$ slon_start 2
+
+# Création des ensemble (ici 1 est le numéro de l'ensemble)
+$ slonik_create_set 1
+
+# Abonner l'ensemble dans le second nœud (1= n° d'ensemble, 2= n° de nœud)
+$ slonik_subscribe_set 1 2 | slonik</programlisting>
+
+<para>
+ Vous avez répliqué votre première base de données. Vous pouvez sauter la
+ section suivante de la documentation si vous le souhaitez car il s'agit
+ d'une approche plus <quote>rustre</quote>.
+</para>
+
+</sect3>
+
+<sect3>
+<title>Utiliser directement les commandes slonik</title>
+
+<para>
+ L'approche traditionnelle pour administrer slony consiste à utiliser
+ directement les commandes slonik. En voici un exemple.
+</para>
+
+<para>
+ Le script de création de la configuration initiale pour une simple
+ configuration maître-esclave de la base <application>pgbench</application>
+ est le suivant :
+</para>
+
+<programlisting><![CDATA[
+#!/bin/sh
+
+slonik <<_EOF_
+ #--
+ # définition de l'espace de nom du système de réplication
+ # dans notre exemple, il s'agit de exemple_slony
+ #--
+ cluster name = $CLUSTERNAME;
+
+ #--
+ # les paramètres "admin conninfo" sont utilisé par slonik pour se
+ # connecter aux noeuds. Une ligne par noeud. La syntaxe est celle de
+ # PQconnectdb de l'API C
+ # --
+ node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER';
+ node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST user=$REPLICATIONUSER';
+
+ #--
+ # initialisation du premier noeud. Son identifiant DOIT être 1. Cela
+ # provoque la création du schéma _$CLUSTERNAME contenant tous les objets
+ # spécifiques du système de réplication
+ #--
+ init cluster ( id=1, comment = 'Master Node');
+
+ #--
+ # Puisque la table history n'a pas de clé primaire, ni de contrainte
+ # unique qui pourrait être utilisée pour identifier une ligne, nous
+ # devons en ajouter une.
+ # La commande suivante ajoute à la table une colonne bigint nommée
+ # _Slony-I_$CLUSTERNAME_rowID. Elle comme valeur par défaut
+ # nextval('_$CLUSTERNAME.s1_rowid_seq'), et dispose des contraintes
+ # UNIQUE et NOT NULL. Toutes les lignes existantes seront initialisées
+ # avec un dentifiant.
+ #--
+ table add key (node id = 1, fully qualified name = 'public.history');
+
+ #--
+ # Slony-I regroupe les tables dans des ensembles.
+ # La plus petite unité qu'un noeud peut répliquer est un ensemble.
+ # Les commandes suivantes crées un ensemble contenant 4 tables pgbench.
+ # Le maître (ou origine) de l'ensemble est le noeud 1.
+ #--
+ create set (id=1, origin=1, comment='All pgbench tables');
+ set add table (set id=1, origin=1, id=1, fully qualified name = 'public.accounts', comment='accounts table');
+ set add table (set id=1, origin=1, id=2, fully qualified name = 'public.branches', comment='branches table');
+ set add table (set id=1, origin=1, id=3, fully qualified name = 'public.tellers', comment='tellers table');
+ set add table (set id=1, origin=1, id=4, fully qualified name = 'public.history', comment='history table', key = serial);
+
+ #--
+ # Création du second noeud (l'esclave)
+ # décrit comment les 2 noeuds vont se connecter l'un à l'autre
+ # et quelle manière ils vont écouter les événements..
+ #--
+ store node (id=2, comment = 'Slave node');
+ store path (server = 1, client = 2, conninfo='dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER');
+ store path (server = 2, client = 1, conninfo='dbname=$SLAVEDBNAME host=$SLAVEHOST user=$REPLICATIONUSER');
+_EOF_
+]]></programlisting>
+
+<para>
+ L'application <application>pgbench</application> est-elle toujours
+ exécutée ? Si ce n'est pas le cas, redémarrez-la.
+</para>
+
+<para>
+ À ce moment, nous avons deux bases de données qui sont complètement préparées.
+ L'une d'elle est la base maître, celle que l'application
+ <application>pgbench</application> utilise pour lire et modifier des lignes.
+ Le temps est donc venu de lancer les démons de réplication.
+</para>
+
+<para>
+ Sur $MASTERHOST, la commande pour démarrer le moteur de réplication est :
+
+ <programlisting>slon $CLUSTERNAME "dbname=$MASTERDBNAME user=$REPLICATIONUSER host=$MASTERHOST"</programlisting>
+</para>
+
+<para>
+ De la même façon, nous démarrons le système de réplication sur le nœud 2
+ (l'esclave) :
+
+ <programlisting>slon $CLUSTERNAME "dbname=$SLAVEDBNAME user=$REPLICATIONUSER host=$SLAVEHOST"</programlisting>
+</para>
+
+<para>
+ Même si nous avons désormais le démon <xref linkend="slon"/> exécuté à la fois
+ sur le maître et l'esclave, et qu'ils sont tous les deux en train de cracher
+ des diagnostiques et d'autres messages, les données ne sont toujours pas
+ répliquées. L'activité que vous constatez est la synchronisation de la
+ configuration du cluster entre les deux processus <xref linkend="slon"/>.
+</para>
+
+<para>
+ Pour démarrer la réplication des quatre tables <application>pgbench</application>
+ (l'ensemble 1) depuis le maître (le nœud 1) vers l'esclave (le
+ nœud 2), lancez le script suivant :
+
+ <programlisting><![CDATA[
+#!/bin/sh
+slonik <<_EOF_
+ # ----
+ # Définition de l'espace de nom du cluster
+ # ----
+ cluster name = $CLUSTERNAME;
+
+ # ----
+ # Les paramètres conninfo sont utilisés par le programme slonik
+ # pour se connecter aux noeuds. Ce sont donc les arguments
+ # PQconnectdb pour se connecter depuis la station de travail
+ # d'administration (où les scripts slonik sont exécutés).
+ # ----
+ node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER';
+ node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST user=$REPLICATIONUSER';
+
+ # ----
+ # Le noeud 2 s'abonne à l'ensemble 1
+ # ----
+ subscribe set ( id = 1, provider = 1, receiver = 2, forward = no);
+_EOF_]]></programlisting>
+
+</para>
+
+<para>
+ Désormais, le démon de réplication sur<envar>$SLAVEHOST</envar> se
+ déclenchera à tout moment pour copier les changements d'états sur les quatre
+ tables répliquées. Pendant ce temps, l'application
+ <application>pgbench</application> va continuer à modifier la base de données.
+ Lorsque le processus de copie est terminé, le démon de réplication sur le
+ nœud <envar>$SLAVEHOST</envar> commencera à se synchroniser en
+ appliquant les journaux de réplication qui auront été accumulés. Cela se
+ fera par petit à petit, par tranches de 10 secondes de travail applicatifs.
+ Selon les performances des deux systèmes impliqués, la taille des deux bases
+ de données, la charge de transaction et la qualité de l'optimisation et de la
+ maintenance effectuées sur les deux bases de données, ce processus de
+ synchronisation peut durer quelques minutes, quelques heures ou quelques
+ siècles.
+</para>
+
+<para>
+ Vous avez maintenant configuré avec succès votre premier système de
+ réplication maître-esclave basique, et les deux bases de données devraient,
+ une fois que l'esclave sera synchronisé, contenir des données identiques. Ça,
+ c'est la théorie, tout du moins. En pratique, il est bon de vérifier que les
+ ensembles de données sont bien identiques.
+</para>
+
+<para>
+ Le script ci-dessous crée des sauvegardes ordonnées des deux bases et les
+ compare. Assurez-vous que le test <application>pgbench</application> est
+ terminé, qu'il n'y pas d'autres mises à jour en cours sur le nœud
+ origine, et que les sessions slon se sont synchronisées.
+</para>
+
+<programlisting><![CDATA[
+#!/bin/sh
+echo -n "**** comparing sample1 ... "
+psql -U $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME >dump.tmp.1.$$ <<_EOF_
+ select 'accounts:'::text, aid, bid, abalance, filler
+ from accounts order by aid;
+ select 'branches:'::text, bid, bbalance, filler
+ from branches order by bid;
+ select 'tellers:'::text, tid, bid, tbalance, filler
+ from tellers order by tid;
+ select 'history:'::text, tid, bid, aid, delta, mtime, filler,
+ "_Slony-I_${CLUSTERNAME}_rowID"
+ from history order by "_Slony-I_${CLUSTERNAME}_rowID";
+_EOF_
+psql -U $REPLICATIONUSER -h $SLAVEHOST $SLAVEDBNAME >dump.tmp.2.$$ <<_EOF_
+ select 'accounts:'::text, aid, bid, abalance, filler
+ from accounts order by aid;
+ select 'branches:'::text, bid, bbalance, filler
+ from branches order by bid;
+ select 'tellers:'::text, tid, bid, tbalance, filler
+ from tellers order by tid;
+ select 'history:'::text, tid, bid, aid, delta, mtime, filler,
+ "_Slony-I_${CLUSTERNAME}_rowID"
+ from history order by "_Slony-I_${CLUSTERNAME}_rowID";
+_EOF_
+
+if diff dump.tmp.1.$$ dump.tmp.2.$$ >$CLUSTERNAME.diff ; then
+ echo "success - databases are equal."
+ rm dump.tmp.?.$$
+ rm $CLUSTERNAME.diff
+else
+ echo "FAILED - see $CLUSTERNAME.diff for database differences"
+fi
+]]></programlisting>
+
+<para>
+ Notez qu'il existe une documentation un peu plus sophistiquée concernant ce
+ processus dans l'arborescence du code source de &slony1; au sein d'un fichier
+ nommé <filename>slony-I-basic-mstr-slv.txt</filename>.
+</para>
+
+<para>
+ Si ce script renvoie <command>FAILED</command>, merci de contacter les
+ développeurs sur <ulink url="http://slony.info/">http://slony.info/</ulink>.
+</para>
+
+</sect3>
+
+</sect2>
+
+</sect1>
Deleted: traduc/tags/slony_1_2_12/installation.xml
===================================================================
--- traduc/trunk/slony/installation.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/installation.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,400 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="installation">
-<title>Installation de &slony1;</title>
-<indexterm><primary>instructions d'installation</primary></indexterm>
-
-<note>
- <para>
- Pour les utilisateurs de &windows; : à moins de modifier le code de
- &slony1;, il est fortement recommandé de télécharger et d'installer une
- version binaire précompilée et de passer directement à la section
- configuration ci-dessous. Vous trouverez les liens et les binaires
- officiels sur le <ulink url="http://pgfoundry.org/projects/slony1/">site de
- &slony1;</ulink>, notamment la version 1.2.0.
- </para>
-
- <para>
- Il existe également des binaires RPM disponibles pour les versions récentes
- de &slony1; et de &postgres;.
- </para>
-</note>
-
-<warning>
- <para>
- Si vous utilisez &slony1; pour remplacer une version antérieure de
- &postgres; par une version récente, ou si vous souhaitez une version issue
- du CVS, en dehors du contexte de la sortie d'une version majeure, alors
- préparez-vous à compiler à la fois &postgres; et &slony1; à partir des
- sources. Cette section est rédigée en supposant que vous avez lu cet
- avertissement...
- </para>
-</warning>
-
-<para>
- Vous devez avoir obtenu les sources de &slony1; à l'étape précédente.
- Décompressez le paquet.
-</para>
-
-<screen>gunzip slony.tar.gz;
-tar xf slony.tar</screen>
-
-<para>
- Ceci va créer un répertoire contenant les sources dans votre répertoire
- courant. Déplacez-vous dans ce répertoire et restez-y pendant toute la
- procédure d'installation.
-</para>
-
-<sect2>
-<title>Version courte</title>
-<indexterm><primary>installation : version courte</primary></indexterm>
-
-<para>
-<screen>PGMAIN=/usr/local/pgsql746-freebsd-2005-04-01 \
-./configure \
- --with-pgconfigdir=$PGMAIN/bin
-gmake all; gmake install
-</screen>
-</para>
-
-</sect2>
-
-<sect2>
-<title>Configuration</title>
-<indexterm><primary>instructions de configuration</primary></indexterm>
-
-<para>
- Normalement, &slony1; doit être compilé et installé avec le compte Unix
- &postgres;. La cible de l'installation doit être identique à l'installation
- &postgres; existante, notamment parce que plusieurs composants de &slony1;
- sont des bibliothèques et des scripts SQL qui doivent être dans les
- répertoires <filename>lib</filename> et <filename>share</filename> de
- &slony1;.
-</para>
-
-<para>
- La première étape de la procédure d'installation est de configurer l'arbre
- des sources pour votre système. Ceci se fait en lançant le script
- <application>configure</application>. Dans les versions précédentes,
- <application>configure</application> devait savoir où se trouvait l'arbre
- des sources de &postgres;, ce qui était renseigné avec l'option
- <option>--with-pgsourcetree=</option>. À partir de la version 1.1, ceci
- n'est plus nécessaire car &slony1; inclut dans son propre code applicatif
- certaines parties nécessaire pour faciliter la porbabilité entre les
- différentes plates-formes. Désormais, il suffit de faire référence à des
- composants de &postgres; qui font partie de l'installation. Ainsi, &slony1;
- est configuré en pointant vers les différentes répertoire de &postgres; :
- binaires, bibliothèques et fichiers d'en-tête. Pour une liste complète de ces
- options, utilisez la commande <command>./configure --help</command>.
-</para>
-
-<para>
- <emphasis>Normalement</emphasis>, il est suffisant d'exécuter
- <command>configure<option>--with-pgconfigdir=/un/certain/chemin</option></command>,
- où <filename>/un/certain/chemin</filename> est l'emplacement où se situe le
- programme <application>pg_config</application> de &postgres;. À partir de
- <application>pg_config</application>, le script <filename>configure</filename>
- peut déterminer les divers emplacements des composants &postgres;, ce qui
- permet de déduire où installer les composants essentiels de &slony1;.
-</para>
-
-<para>
- Sur certaines plate-formes (AIX et Solaris sont connus pour cela mais pas
- Linux), la compilation de &postgres; doit être expressement configuré avec
- l'option <command>--enable-thread-safety</command> pour fournir les
- bibliothèques clients correctes.
-</para>
-
-<para>
- La version 8 de &postgres; installe les fichiers d'en-tête
- <command>#include</command> par défaut. Avec les versions 7.4 et antérieures,
- vous devez vous assurer que la compilation inclut la commande <command>make
- install-all-headers</command>, sinon les en-têtes du serveur ne seront pas
- installés et &slony1; ne pourra pas être compilé.
-</para>
-
-<para>
- Après avoir lancé configure, vous pouvez ouvrir le fichier
- <filename>Makefile.global</filename> pour vous assurer qu'il recherche tous
- les composants dans les bons emplacements.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Exemple</title>
-
-<para>
- Après avoir déterminé que l'instance &postgres; est installé dans
- <filename>/opt/dbs/pgsql746-aix-2005-04-01</filename> :
-</para>
-
-<screen>PGMAIN=/opt/dbs/pgsql746-aix-2005-04-01 \
-./configure \
- --with-pgconfigdir=$PGMAIN/bin</screen>
-
-<para>
- Le script <application>configure</application> lance de nombreux tests pour
- deviner les valeurs des différentes variables et tente de détecter certaines
- particularités de votre système. &slony1; est connu pour avoir besoin d'une
- version modifiée de <application>libpq</application> sur des plate-formes
- spécifiques telles que Solaris2.X sur SPARC. Le correctif de la version 7.4.2
- de la libpq se trouvent à l'adresse <ulink id="threadpatch" url=
- "http://developer.postgresql.org/~wieck/slony1/download/threadsafe-libpq-742.diff.gz">
- http://developer.postgresql.org/~wieck/slony1/download/threadsafe-libpq-742.diff.gz
- </ulink>. Des correctifs similaires peuvent être compilés pour d'autres
- versions ; voir l'entrée dans la FAQ intitulée <link
- linkend="threadsafety">sécurité des threads</link>.
-</para>
-
-<para>
- Pour une liste de toutes les options de configuration, lancez la commande
- <command>./configure --help</command>.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Compilation</title>
-
-<para>
- Pour démarrer le processus de compilation, tapez :
- <screen>gmake all</screen>
-</para>
-
-<para>
- Assurez d'utiliser GNU make ; sur les systèmes BSD, il est appelé
- <application>gmake</application> ; sur Linux, GNU make est généralement
- le <application>make</application> <quote>natif</quote>, ainsi le nom de la
- commande que vous devez taper peut être <command>make</command> ou
- <command>gmake</command>. Sur d'autres plate-formes, vous aurez peut-être
- besoin de paquets supplémentaires ou même d'une installation complète de
- GNU make. La compilation prend entre quelques secondes et deux minutes selon
- la rapidité de votre matériel. La dernière ligne affichée devrait être :
-</para>
-
-<para>
- <command>All of Slony-I is successfully made. Ready to install.</command>
-</para>
-
-</sect2>
-
-<sect2>
-<title>Installer &slony1; une fois compilé</title>
-
-<para>
- Pour installer &slony1;, tapez :
- <command>gmake install</command>
-</para>
-
-<para>
- Ceci va installer les fichiers dans le répertoire d'installation de PostgreSQL
- tel que spécifié par l'option <option>--prefix</option> de
- <command>configure</command> utilisé lors de l'installation de &postgres;.
- Assurez-vous que vous avez les droits adéquats pour écrire dans cet
- emplacement. En général, vous devez être soit root ou l'utilisateur postgres.
-</para>
-
-<para>
- Voici la liste des fichiers principaux installés dans l'instance
- PostgreSQL :
-</para>
-
-<itemizedlist>
- <listitem><para><filename> $bindir/slon</filename></para></listitem>
- <listitem><para><filename> $bindir/slonik</filename></para></listitem>
- <listitem><para><filename> $libdir/slony1_funcs$(DLSUFFIX)</filename></para></listitem>
- <listitem><para><filename> $libdir/xxid($DLSUFFIX)</filename></para></listitem>
- <listitem><para><filename> $datadir/slony1_base.sql</filename></para></listitem>
- <listitem><para><filename> $datadir/slony1_base.v73.sql</filename></para></listitem>
- <listitem><para><filename> $datadir/slony1_base.v74.sql</filename></para></listitem>
- <listitem><para><filename> $datadir/slony1_base.v80.sql</filename></para></listitem>
- <listitem><para><filename> $datadir/slony1_funcs.sql</filename></para></listitem>
- <listitem><para><filename> $datadir/slony1_funcs.v73.sql</filename></para></listitem>
- <listitem><para><filename> $datadir/slony1_funcs.v74.sql</filename></para></listitem>
- <listitem><para><filename> $datadir/slony1_funcs.v80.sql</filename></para></listitem>
-</itemizedlist>
-
-<para>
- (Notez qu'au fur et à mesure des versions, la liste des fichiers spécifiques
- à une version va s'agrandir...)
-</para>
-
-<para>
- Les fichiers <filename>.sql</filename> ne sont pas encore complètement
- installés. Les versions 7.3, 7.4 et 8.0 des fichiers sont installés sur
- chaque système, quelque soit la version de &postgres;. L'outil d'administration
- <xref linkend="slonik"/> effectue des substitutions d'espace de noms et de
- cluster dans ces fichiers, puis chargent les fichiers lors de la création d'un
- nœud de réplication. À cet instant, la base de donnée qui est initialisée
- peut être à distance ou utiliser une version différente de &postgres; par
- rapport à la version de l'hôte local.
-</para>
-
-<para>
- Pour terminer, les deux objets partagés installés dans le répertoire
- <filename>$libdir</filename> doivent être installés sur chaque ordinateur
- qui va devenir un nœud &slony1; (d'autres composants peuvent être
- chargés à distance à partir des autres nœuds.).
-</para>
-
-</sect2>
-
-<sect2>
-<title>Compiler la documentation : Guide d'administration</title>
-<indexterm><primary>compiler la documentation &slony1;</primary></indexterm>
-
-<para>
- Le document que vous êtes en train de lire est un <quote>guide
- d'administration</quote> très complet qui contient toute la sagesse
- découverte lors de l'utilisation et la maintenance de &slony1;.</para>
-
-<para>
- Cette documentation est compilé uniquement si vous spécifiez l'option
- <command>--with-docs</command>.
-</para>
-
-<para>
- Notez que vous pouvez rencontrer des difficultés pour compiler la
- documentation sur les systèmes basés sur Red Hat à cause de la valeur NAMELEN
- qui est trop faible. Havoc Pennington a déclaré ce bug au milieu de l'année
- 2001, à l'époque de Red Hat 7.1 ; La société Red Hat Software a reconnu
- ce bug mais il n'y a eu aucun progrès depuis. La seconde URL ci-dessous
- indique qu'il y a eu des tentatives de correction en élevant la valeur de
- NAMELEN dans une future version de Red Hat Enterprise Linux, mais cela n'est
- pas le cas en 2008. La distribution Fedora Core 4 devrait avoir corrigé ce
- problème plus tôt.
-</para>
-
-<para>
- <ulink url="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36058">Bug
- 36058</ulink>
-</para>
-
-<para>
- <ulink url="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159382">Bug
- 159382 (pour RHEL)</ulink>
-</para>
-
-<para>
- Une version pré-compilée du « Guide d'administration » est disponible soit
- sous la forme de paquets d'archive séparés, soit dans le répertoire
- <filename>doc/adminguide/prebuilt</filename>
-</para>
-
-<para>
- Voir le fichier <filename>INSTALL</filename> pour un contournement
- du problème sous Fedora...
-</para>
-
-</sect2>
-
-<sect2>
-<title>Installer &slony1; à partir des RPM</title>
-
-<para>
- Même si &slony1; peut être compilé et exécuté sur la plupart des
- distributions Linux, il est également possible d'installer &slony1; en
- utilisant des paquets binaires. L'équipe de développement de Slony (NdT :
- « Slony Global Development Team ») fournit des paquets RPM et SRPM
- officiels pour différentes versions de Red Hat et Fedora Core.
-</para>
-
-<para>
- Les RPM sont disponibles sur le <ulink
- url="http://pgfoundry.org/projects/slony1/">site &slony1; sur pgFoundry.org
- </ulink>. Lisez le fichier <command>CURRENT_MAINTAINER</command> pour
- plus de détails sur les RPM. Notez que ces RPM rechercheront &postgres; tel
- qu'installé par RPM, donc si vous avez installé &postgres; à partir des
- sources, vous devez ignorer explicitement les dépendances liées à
- &postgres;.
-</para>
-
-<para>
- Installer &slony1; à partir de ces RPM est aussi facile qu'avec n'importe
- quel paquet RPM :
-</para>
-
-<screen>rpm -ivh postgresql-slony1-engine-....rpm</screen>
-
-<para>
- Si vous voulez mettre à jour une version antérieure, utilisez simplement la
- commande <command>rpm -Uvh</command>. Cependant, n'oubliez pas de suivre la
- procédure habituelle de mise à jour.
-</para>
-
-<para>
- Le paquet RPM installe les fichiers à leur emplacements habituels. Les
- fichiers de configuration sont dans le répertoire <filename>/etc</filename>,
- les fichiers binaires sont installés dans <filename>/usr/bin</filename>, les
- bibliothèques sont dans <filename>/usr/lib/pgsql</filename> et enfin la
- documentation est située dans <filename>/usr/share/doc/postgresql-slony1-engine</filename>.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Installer le service &slony1; sur &windows;</title>
-<indexterm><primary>installation &slony1; sur &windows;</primary></indexterm>
-
-<para>
- Sur les systèmes &windows;, au lieu de lancer un démon <xref
- linkend="slon"/> par nœud, un service slon unique est installé et peut
- alors être contrôlé via le panneau de contrôle des
- <command>Services</command> ou à partir de la console de commande en
- utilisant la commande <command>net</command>.
-</para>
-
-<screen>C:\Program Files\PostgreSQL\8.0\bin> slon -regservice my_slon
-Service registered.
-Before you can run Slony, you must also register an engine!
-
-WARNING! Service is registered to run as Local System. You are
-encouraged to change this to a low privilege account to increase
-system security.</screen>
-
-<para>
- Une fois que le service est installé, les nœuds individuels peuvent
- être configurés en enregistrant les fichiers de configuration auprès du
- service :
-</para>
-
-<screen>C:\Program Files\PostgreSQL\8.0\bin> slon -addengine c:\node1.conf
-Engine added.</screen>
-
-<para>
- Les autres commandes sont équivoques : <command>slon -unregservice
-<nom du service></command>, <command>slon -listengines
-<nom du service></command> et <command>slon -delengine
-<nom du service> <config file></command>.
-</para>
-
-<para>
- Pour plus d'informations à propos de la version &windows;, vous pouvez
- consulter les pages suivantes :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <ulink url="http://developer.pgadmin.org/~hiroshi/Slony-I/">Exemple
- d'installation de Slony-I sous Windows (en anglais)</ulink>
- </para>
- </listitem>
-
- <listitem>
- <para>
- <ulink url="http://people.planetpostgresql.org/xzilla/index.php?/archives/200-Alpha-testing-Slony-on-win32-Crib-Notes.html">
- Notes rapides suite à des tests de Slony sous Windows par xzilla (en
- anglais)</ulink>
- </para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/installation.xml (from rev 1244, traduc/trunk/slony/installation.xml)
===================================================================
--- traduc/tags/slony_1_2_12/installation.xml (rev 0)
+++ traduc/tags/slony_1_2_12/installation.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,400 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="installation">
+<title>Installation de &slony1;</title>
+<indexterm><primary>instructions d'installation</primary></indexterm>
+
+<note>
+ <para>
+ Pour les utilisateurs de &windows; : à moins de modifier le code de
+ &slony1;, il est fortement recommandé de télécharger et d'installer une
+ version binaire précompilée et de passer directement à la section
+ configuration ci-dessous. Vous trouverez les liens et les binaires
+ officiels sur le <ulink url="http://pgfoundry.org/projects/slony1/">site de
+ &slony1;</ulink>, notamment la version 1.2.0.
+ </para>
+
+ <para>
+ Il existe également des binaires RPM disponibles pour les versions récentes
+ de &slony1; et de &postgres;.
+ </para>
+</note>
+
+<warning>
+ <para>
+ Si vous utilisez &slony1; pour remplacer une version antérieure de
+ &postgres; par une version récente, ou si vous souhaitez une version issue
+ du CVS, en dehors du contexte de la sortie d'une version majeure, alors
+ préparez-vous à compiler à la fois &postgres; et &slony1; à partir des
+ sources. Cette section est rédigée en supposant que vous avez lu cet
+ avertissement...
+ </para>
+</warning>
+
+<para>
+ Vous devez avoir obtenu les sources de &slony1; à l'étape précédente.
+ Décompressez le paquet.
+</para>
+
+<screen>gunzip slony.tar.gz;
+tar xf slony.tar</screen>
+
+<para>
+ Ceci va créer un répertoire contenant les sources dans votre répertoire
+ courant. Déplacez-vous dans ce répertoire et restez-y pendant toute la
+ procédure d'installation.
+</para>
+
+<sect2>
+<title>Version courte</title>
+<indexterm><primary>installation : version courte</primary></indexterm>
+
+<para>
+<screen>PGMAIN=/usr/local/pgsql746-freebsd-2005-04-01 \
+./configure \
+ --with-pgconfigdir=$PGMAIN/bin
+gmake all; gmake install
+</screen>
+</para>
+
+</sect2>
+
+<sect2>
+<title>Configuration</title>
+<indexterm><primary>instructions de configuration</primary></indexterm>
+
+<para>
+ Normalement, &slony1; doit être compilé et installé avec le compte Unix
+ &postgres;. La cible de l'installation doit être identique à l'installation
+ &postgres; existante, notamment parce que plusieurs composants de &slony1;
+ sont des bibliothèques et des scripts SQL qui doivent être dans les
+ répertoires <filename>lib</filename> et <filename>share</filename> de
+ &slony1;.
+</para>
+
+<para>
+ La première étape de la procédure d'installation est de configurer l'arbre
+ des sources pour votre système. Ceci se fait en lançant le script
+ <application>configure</application>. Dans les versions précédentes,
+ <application>configure</application> devait savoir où se trouvait l'arbre
+ des sources de &postgres;, ce qui était renseigné avec l'option
+ <option>--with-pgsourcetree=</option>. À partir de la version 1.1, ceci
+ n'est plus nécessaire car &slony1; inclut dans son propre code applicatif
+ certaines parties nécessaire pour faciliter la porbabilité entre les
+ différentes plates-formes. Désormais, il suffit de faire référence à des
+ composants de &postgres; qui font partie de l'installation. Ainsi, &slony1;
+ est configuré en pointant vers les différentes répertoire de &postgres; :
+ binaires, bibliothèques et fichiers d'en-tête. Pour une liste complète de ces
+ options, utilisez la commande <command>./configure --help</command>.
+</para>
+
+<para>
+ <emphasis>Normalement</emphasis>, il est suffisant d'exécuter
+ <command>configure<option>--with-pgconfigdir=/un/certain/chemin</option></command>,
+ où <filename>/un/certain/chemin</filename> est l'emplacement où se situe le
+ programme <application>pg_config</application> de &postgres;. À partir de
+ <application>pg_config</application>, le script <filename>configure</filename>
+ peut déterminer les divers emplacements des composants &postgres;, ce qui
+ permet de déduire où installer les composants essentiels de &slony1;.
+</para>
+
+<para>
+ Sur certaines plate-formes (AIX et Solaris sont connus pour cela mais pas
+ Linux), la compilation de &postgres; doit être expressement configuré avec
+ l'option <command>--enable-thread-safety</command> pour fournir les
+ bibliothèques clients correctes.
+</para>
+
+<para>
+ La version 8 de &postgres; installe les fichiers d'en-tête
+ <command>#include</command> par défaut. Avec les versions 7.4 et antérieures,
+ vous devez vous assurer que la compilation inclut la commande <command>make
+ install-all-headers</command>, sinon les en-têtes du serveur ne seront pas
+ installés et &slony1; ne pourra pas être compilé.
+</para>
+
+<para>
+ Après avoir lancé configure, vous pouvez ouvrir le fichier
+ <filename>Makefile.global</filename> pour vous assurer qu'il recherche tous
+ les composants dans les bons emplacements.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Exemple</title>
+
+<para>
+ Après avoir déterminé que l'instance &postgres; est installé dans
+ <filename>/opt/dbs/pgsql746-aix-2005-04-01</filename> :
+</para>
+
+<screen>PGMAIN=/opt/dbs/pgsql746-aix-2005-04-01 \
+./configure \
+ --with-pgconfigdir=$PGMAIN/bin</screen>
+
+<para>
+ Le script <application>configure</application> lance de nombreux tests pour
+ deviner les valeurs des différentes variables et tente de détecter certaines
+ particularités de votre système. &slony1; est connu pour avoir besoin d'une
+ version modifiée de <application>libpq</application> sur des plate-formes
+ spécifiques telles que Solaris2.X sur SPARC. Le correctif de la version 7.4.2
+ de la libpq se trouvent à l'adresse <ulink id="threadpatch" url=
+ "http://developer.postgresql.org/~wieck/slony1/download/threadsafe-libpq-742.diff.gz">
+ http://developer.postgresql.org/~wieck/slony1/download/threadsafe-libpq-742.diff.gz
+ </ulink>. Des correctifs similaires peuvent être compilés pour d'autres
+ versions ; voir l'entrée dans la FAQ intitulée <link
+ linkend="threadsafety">sécurité des threads</link>.
+</para>
+
+<para>
+ Pour une liste de toutes les options de configuration, lancez la commande
+ <command>./configure --help</command>.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Compilation</title>
+
+<para>
+ Pour démarrer le processus de compilation, tapez :
+ <screen>gmake all</screen>
+</para>
+
+<para>
+ Assurez d'utiliser GNU make ; sur les systèmes BSD, il est appelé
+ <application>gmake</application> ; sur Linux, GNU make est généralement
+ le <application>make</application> <quote>natif</quote>, ainsi le nom de la
+ commande que vous devez taper peut être <command>make</command> ou
+ <command>gmake</command>. Sur d'autres plate-formes, vous aurez peut-être
+ besoin de paquets supplémentaires ou même d'une installation complète de
+ GNU make. La compilation prend entre quelques secondes et deux minutes selon
+ la rapidité de votre matériel. La dernière ligne affichée devrait être :
+</para>
+
+<para>
+ <command>All of Slony-I is successfully made. Ready to install.</command>
+</para>
+
+</sect2>
+
+<sect2>
+<title>Installer &slony1; une fois compilé</title>
+
+<para>
+ Pour installer &slony1;, tapez :
+ <command>gmake install</command>
+</para>
+
+<para>
+ Ceci va installer les fichiers dans le répertoire d'installation de PostgreSQL
+ tel que spécifié par l'option <option>--prefix</option> de
+ <command>configure</command> utilisé lors de l'installation de &postgres;.
+ Assurez-vous que vous avez les droits adéquats pour écrire dans cet
+ emplacement. En général, vous devez être soit root ou l'utilisateur postgres.
+</para>
+
+<para>
+ Voici la liste des fichiers principaux installés dans l'instance
+ PostgreSQL :
+</para>
+
+<itemizedlist>
+ <listitem><para><filename> $bindir/slon</filename></para></listitem>
+ <listitem><para><filename> $bindir/slonik</filename></para></listitem>
+ <listitem><para><filename> $libdir/slony1_funcs$(DLSUFFIX)</filename></para></listitem>
+ <listitem><para><filename> $libdir/xxid($DLSUFFIX)</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_base.sql</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_base.v73.sql</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_base.v74.sql</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_base.v80.sql</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_funcs.sql</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_funcs.v73.sql</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_funcs.v74.sql</filename></para></listitem>
+ <listitem><para><filename> $datadir/slony1_funcs.v80.sql</filename></para></listitem>
+</itemizedlist>
+
+<para>
+ (Notez qu'au fur et à mesure des versions, la liste des fichiers spécifiques
+ à une version va s'agrandir...)
+</para>
+
+<para>
+ Les fichiers <filename>.sql</filename> ne sont pas encore complètement
+ installés. Les versions 7.3, 7.4 et 8.0 des fichiers sont installés sur
+ chaque système, quelque soit la version de &postgres;. L'outil d'administration
+ <xref linkend="slonik"/> effectue des substitutions d'espace de noms et de
+ cluster dans ces fichiers, puis chargent les fichiers lors de la création d'un
+ nœud de réplication. À cet instant, la base de donnée qui est initialisée
+ peut être à distance ou utiliser une version différente de &postgres; par
+ rapport à la version de l'hôte local.
+</para>
+
+<para>
+ Pour terminer, les deux objets partagés installés dans le répertoire
+ <filename>$libdir</filename> doivent être installés sur chaque ordinateur
+ qui va devenir un nœud &slony1; (d'autres composants peuvent être
+ chargés à distance à partir des autres nœuds.).
+</para>
+
+</sect2>
+
+<sect2>
+<title>Compiler la documentation : Guide d'administration</title>
+<indexterm><primary>compiler la documentation &slony1;</primary></indexterm>
+
+<para>
+ Le document que vous êtes en train de lire est un <quote>guide
+ d'administration</quote> très complet qui contient toute la sagesse
+ découverte lors de l'utilisation et la maintenance de &slony1;.</para>
+
+<para>
+ Cette documentation est compilé uniquement si vous spécifiez l'option
+ <command>--with-docs</command>.
+</para>
+
+<para>
+ Notez que vous pouvez rencontrer des difficultés pour compiler la
+ documentation sur les systèmes basés sur Red Hat à cause de la valeur NAMELEN
+ qui est trop faible. Havoc Pennington a déclaré ce bug au milieu de l'année
+ 2001, à l'époque de Red Hat 7.1 ; La société Red Hat Software a reconnu
+ ce bug mais il n'y a eu aucun progrès depuis. La seconde URL ci-dessous
+ indique qu'il y a eu des tentatives de correction en élevant la valeur de
+ NAMELEN dans une future version de Red Hat Enterprise Linux, mais cela n'est
+ pas le cas en 2005. La distribution Fedora Core 4 devrait avoir corrigé ce
+ problème plus tôt.
+</para>
+
+<para>
+ <ulink url="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36058">Bug
+ 36058</ulink>
+</para>
+
+<para>
+ <ulink url="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159382">Bug
+ 159382 (pour RHEL)</ulink>
+</para>
+
+<para>
+ Une version pré-compilée du « Guide d'administration » est disponible soit
+ sous la forme de paquets d'archive séparés, soit dans le répertoire
+ <filename>doc/adminguide/prebuilt</filename>
+</para>
+
+<para>
+ Voir le fichier <filename>INSTALL</filename> pour un contournement
+ du problème sous Fedora...
+</para>
+
+</sect2>
+
+<sect2>
+<title>Installer &slony1; à partir des RPM</title>
+
+<para>
+ Même si &slony1; peut être compilé et exécuté sur la plupart des
+ distributions Linux, il est également possible d'installer &slony1; en
+ utilisant des paquets binaires. L'équipe de développement de Slony (NdT :
+ « Slony Global Development Team ») fournit des paquets RPM et SRPM
+ officiels pour différentes versions de Red Hat et Fedora Core.
+</para>
+
+<para>
+ Les RPM sont disponibles sur le <ulink
+ url="http://pgfoundry.org/projects/slony1/">site &slony1; sur pgFoundry.org
+ </ulink>. Lisez le fichier <command>CURRENT_MAINTAINER</command> pour
+ plus de détails sur les RPM. Notez que ces RPM rechercheront &postgres; tel
+ qu'installé par RPM, donc si vous avez installé &postgres; à partir des
+ sources, vous devez ignorer explicitement les dépendances liées à
+ &postgres;.
+</para>
+
+<para>
+ Installer &slony1; à partir de ces RPM est aussi facile qu'avec n'importe
+ quel paquet RPM :
+</para>
+
+<screen>rpm -ivh postgresql-slony1-engine-....rpm</screen>
+
+<para>
+ Si vous voulez mettre à jour une version antérieure, utilisez simplement la
+ commande <command>rpm -Uvh</command>. Cependant, n'oubliez pas de suivre la
+ procédure habituelle de mise à jour.
+</para>
+
+<para>
+ Le paquet RPM installe les fichiers à leur emplacements habituels. Les
+ fichiers de configuration sont dans le répertoire <filename>/etc</filename>,
+ les fichiers binaires sont installés dans <filename>/usr/bin</filename>, les
+ bibliothèques sont dans <filename>/usr/lib/pgsql</filename> et enfin la
+ documentation est située dans <filename>/usr/share/doc/postgresql-slony1-engine</filename>.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Installer le service &slony1; sur &windows;</title>
+<indexterm><primary>installation &slony1; sur &windows;</primary></indexterm>
+
+<para>
+ Sur les systèmes &windows;, au lieu de lancer un démon <xref
+ linkend="slon"/> par nœud, un service slon unique est installé et peut
+ alors être contrôlé via le panneau de contrôle des
+ <command>Services</command> ou à partir de la console de commande en
+ utilisant la commande <command>net</command>.
+</para>
+
+<screen>C:\Program Files\PostgreSQL\8.0\bin> slon -regservice my_slon
+Service registered.
+Before you can run Slony, you must also register an engine!
+
+WARNING! Service is registered to run as Local System. You are
+encouraged to change this to a low privilege account to increase
+system security.</screen>
+
+<para>
+ Une fois que le service est installé, les nœuds individuels peuvent
+ être configurés en enregistrant les fichiers de configuration auprès du
+ service :
+</para>
+
+<screen>C:\Program Files\PostgreSQL\8.0\bin> slon -addengine c:\node1.conf
+Engine added.</screen>
+
+<para>
+ Les autres commandes sont équivoques : <command>slon -unregservice
+<nom du service></command>, <command>slon -listengines
+<nom du service></command> et <command>slon -delengine
+<nom du service> <config file></command>.
+</para>
+
+<para>
+ Pour plus d'informations à propos de la version &windows;, vous pouvez
+ consulter les pages suivantes :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://developer.pgadmin.org/~hiroshi/Slony-I/">Exemple
+ d'installation de Slony-I sous Windows (en anglais)</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <ulink url="http://people.planetpostgresql.org/xzilla/index.php?/archives/200-Alpha-testing-Slony-on-win32-Crib-Notes.html">
+ Notes rapides suite à des tests de Slony sous Windows par xzilla (en
+ anglais)</ulink>
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
+</sect1>
Deleted: traduc/tags/slony_1_2_12/legal.xml
===================================================================
--- traduc/trunk/slony/legal.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/legal.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,53 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<copyright>
- <year>2004-2007</year>
- <holder>The PostgreSQL Global Development Group</holder>
-</copyright>
-
-<legalnotice id="legalnotice">
- <title>Notice légale</title>
-
- <para>
- <productname>PostgreSQL</productname> est sous le Copyright &copy; 2004-2007
- du PostgreSQL Global Development Group et est distribué sous les termes
- de la licence de l'Université de Californie ci-dessous.
- </para>
-
- <para>
- La permission d'utiliser, copier, modifier et distribuer ce logiciel
- et sa documentation pour tout usage, sans frais et sans accord écrit,
- est assurée à la condition que cette notice de copyright et ce paragraphe
- ainsi que les deux paragraphes suivants apparaissent dans toutes les copies.
- </para>
-
- <para>
- EN AUCUN CAS, L'UNIVERSITÉ DE CALIFORNIE NE POURRA ÊTRE TENUE RESPONSABLE
- POUR DES DOMMAGES DIRECTS, INDIRECTS, SPECIAUX, LES INCIDENTS ET LES
- CONSÉQUENCES, Y COMPRIS LES PERTES FINANCIERES RÉSULTANTS DE L'UTILISATION
- DE CE LOGICIEL ET DE SA DOCUMENTATION, MÊME SI L'UNIVERSITÉ DE CALIFORNIE A
- ÉTÉ AVERTIE DE LA POSSIBILITÉ DE TELS DOMMAGES.
- </para>
-
- <para>
- L'UNIVERSITÉ DE CALIFORNIE REFUSE SPECIFIQUEMENT TOUTE GARANTIE,
- CELA IMPLIQUE, SANS SE LIMITER À CELA, LES GARANTIES DE COMMERCIALISATION
- ET CORRESPONDANCE À UN USAGE PARTICULIER. LE LOGICIEL EST FOURNI
- <quote>TEL QUEL</quote> ET L'UNIVERSITÉ DE CALIFORNIE N'A AUCUNE OBLIGATION D'EN
- ASSURER LA MAINTENANCE, LE SUPPORT, LES MISES À JOUR OU LES MODIFICATIONS.
- </para>
-
- <para>
- Notez que <trademark>UNIX</trademark> est une marque déposée par The
- Open Group. &windows; est une marque déposée par Microsoft Corporation
- aux États-Unis d'Amérique et dans d'autres pays.
- <trademark>Solaris</trademark> est une marque déposée par Sun Microsystems,
- Inc. <trademark>Linux</trademark> est une marque déposée par Linus Torvalds.
- <trademark>AIX</trademark> est une marque déposée par IBM.
- </para>
-
-</legalnotice>
Copied: traduc/tags/slony_1_2_12/legal.xml (from rev 1244, traduc/trunk/slony/legal.xml)
===================================================================
--- traduc/tags/slony_1_2_12/legal.xml (rev 0)
+++ traduc/tags/slony_1_2_12/legal.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,53 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<copyright>
+ <year>2004-2006</year>
+ <holder>The PostgreSQL Global Development Group</holder>
+</copyright>
+
+<legalnotice id="legalnotice">
+ <title>Notice légale</title>
+
+ <para>
+ <productname>PostgreSQL</productname> est sous le Copyright &copy; 2004-2006
+ du PostgreSQL Global Development Group et est distribué sous les termes
+ de la licence de l'Université de Californie ci-dessous.
+ </para>
+
+ <para>
+ La permission d'utiliser, copier, modifier et distribuer ce logiciel
+ et sa documentation pour tout usage, sans frais et sans accord écrit,
+ est assurée à la condition que cette notice de copyright et ce paragraphe
+ ainsi que les deux paragraphes suivants apparaissent dans toutes les copies.
+ </para>
+
+ <para>
+ EN AUCUN CAS, L'UNIVERSITÉ DE CALIFORNIE NE POURRA ÊTRE TENUE RESPONSABLE
+ POUR DES DOMMAGES DIRECTS, INDIRECTS, SPECIAUX, LES INCIDENTS ET LES
+ CONSÉQUENCES, Y COMPRIS LES PERTES FINANCIERES RÉSULTANTS DE L'UTILISATION
+ DE CE LOGICIEL ET DE SA DOCUMENTATION, MÊME SI L'UNIVERSITÉ DE CALIFORNIE A
+ ÉTÉ AVERTIE DE LA POSSIBILITÉ DE TELS DOMMAGES.
+ </para>
+
+ <para>
+ L'UNIVERSITÉ DE CALIFORNIE REFUSE SPECIFIQUEMENT TOUTE GARANTIE,
+ CELA IMPLIQUE, SANS SE LIMITER À CELA, LES GARANTIES DE COMMERCIALISATION
+ ET CORRESPONDANCE À UN USAGE PARTICULIER. LE LOGICIEL EST FOURNI
+ <quote>TEL QUEL</quote> ET L'UNIVERSITÉ DE CALIFORNIE N'A AUCUNE OBLIGATION D'EN
+ ASSURER LA MAINTENANCE, LE SUPPORT, LES MISES À JOUR OU LES MODIFICATIONS.
+ </para>
+
+ <para>
+ Notez que <trademark>UNIX</trademark> est une marque déposée par The
+ Open Group. &windows; est une marque déposée par Microsoft Corporation
+ aux États-Unis d'Amérique et dans d'autres pays.
+ <trademark>Solaris</trademark> est une marque déposée par Sun Microsystems,
+ Inc. <trademark>Linux</trademark> est une marque déposée par Linus Torvalds.
+ <trademark>AIX</trademark> est une marque déposée par IBM.
+ </para>
+
+</legalnotice>
Deleted: traduc/tags/slony_1_2_12/loganalysis.xml
===================================================================
--- traduc/trunk/slony/loganalysis.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/loganalysis.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,2391 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="loganalysis">
-<title>Analyses des traces</title>
-<indexterm><primary>analyse des traces</primary></indexterm>
-
-<para>
- Voici un tour d'horizon des informations que vous trouverez dans les traces
- de &slony1;, ainsi que des explications sur leur signification.
-</para>
-
-<sect2>
-<title>Notification CONFIG</title>
-
-<para>
- Ces lignes sont assez triviales. Ce sont des messages d'information à propos
- de la configuration.
-</para>
-
-<para>
- Voici quelques lignes typiques que vous pouvez rencontrer :
- <screen>CONFIG main: local node id = 1
-CONFIG main: loading current cluster configuration
-CONFIG storeNode: no_id=3 no_comment='Node 3'
-CONFIG storePath: pa_server=5 pa_client=1 pa_conninfo="host=127.0.0.1 dbname=foo user=postgres port=6132" pa_connretry=10
-CONFIG storeListen: li_origin=3 li_receiver=1 li_provider=3
-CONFIG storeSet: set_id=1 set_origin=1 set_comment='Set 1'
-CONFIG main: configuration complete - starting threads</screen>
-</para>
-
-</sect2>
-
-<sect2>
-<title>Notifications INFO</title>
-
-<para>
- Les événements, qui semblent avoir un intérêt au niveau INFO et qui sont
- toujours listés, tout comme les notifications CONFIG.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Notifications DEBUG</title>
-
-<para>
- Les notifications DEBUG sont moins intéressantes et ne vous seront utiles
- que lorsque vous rencontrez une problème avec &slony1;.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Nom du processus </title>
-
-<para>
- Les notifications sont toujours précédées par le nom du processus qui produit
- cette notification. Vous verrez des messages en provenance des processus
- suivants :
-
- <variablelist>
- <varlistentry>
- <term>localListenThread</term>
- <listitem>
- <para>
- Le processus local qui écoute les événements sur le nœud local.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>remoteWorkerThread-X</term>
- <listitem>
- <para>
- Les processus qui traitent les événements distants. Vous verrez un de
- ces processus pour chaque nœud qui est en communication avec le
- nœud local.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>remoteListenThread-X</term>
- <listitem>
- <para>
- Les processus qui écoutent les événements distants. Vous verrez un
- de ces processus pour chaque nœud du cluster.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>cleanupThread</term>
- <listitem>
- <para>
- Le processus qui prend en charge les opérations telles que les
- VACUUM, le nettoyage des tables confirm et event et la suppression
- des données périmées.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>syncThread</term>
- <listitem>
- <para>
- Le processus qui produit les événements SYNC.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-</para>
-
-<para>
- La quantité d'information que ces processus affichent est contrôlée par le
- paramètre <envar>log_level</envar> de &lslon;. Les messages de type
- ERROR/WARN/CONFIG/INFO seront toujours affichés. Augmenter la valeur de 1 à
- 4 affichera des plus en plus de messages de niveau DEBUG.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Comment lire les traces de &slony1;</title>
-<indexterm><primary>lire et comprendre les traces de &slony1;</primary></indexterm>
-
-<para>
- Notons que, du point de vue d'un processus slon, il n'y a pas de
- <quote>maître</quote> ni d'<quote>esclave</quote>. Il y a juste des
- nœuds.
-</para>
-
-<para>
- On s'attend, de prime abord, à voir sur chaque nœuds des événements se
- propager dans les deux sens. Dans un premier temps, il doit y avoir des
- événements publiés qui témoignent de la création des nœuds et des
- voies de communications. Si vous ne les voyez pas, alors les nœuds
- ne communiquent pas correctement entre eux et rien ne va se passer...
-</para>
-
-<itemizedlist>
- <listitem>
- <para>Créer les deux nœuds.</para>
-
- <para>
- Aucun slon ne fonctionne à ce stade, donc il n'y a aucune trace à
- consulter.
- </para>
- </listitem>
-
- <listitem>
- <para>Lancer les deux nœuds</para>
-
- <para>
- Les traces de chaque nœud n'auront pas une activité débordante
- car aucun des nœuds n'a pas grand chose à dire et qu'ils ne savent
- pas comment communiquer entre eux. Chaque nœud génère périodiquement
- un événement <command>SYNC</command>, mais ne perçoit
- <emphasis>rien</emphasis> de ce qui se passe sur les autres nœuds.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Lancer <xref linkend="stmtstorepath"/> pour configurer les voies de
- communications. Ceci devrait permettre aux nœuds de prendre
- conscience de l'existence de leurs voisins.
- </para>
-
- <para>
- Les traces de slon doivent maintenant indiquer la réception des événements
- en provenance des nœuds <quote>étrangers</quote>.
- </para>
-
- <para>
- Dans la 1.0, <xref linkend="table.sl-listen"/> n'est pas configuré
- automatiquement, donc les traces vont rester calmes tant que vous n'aurez
- pas soumis explicitement les requêtes <command>STORE LISTEN</command>.
- Dans la version 1.1, les <quote>voies d'écoute</quote> sont configurées
- automatiquement, ce qui nous donne un réseau de communication
- opérationnel plus rapidement.
- </para>
-
- <para>
- Si vous consultez le contenu des tables <xref linkend="table.sl-node"/>,
- <xref linkend="table.sl-path"/> et <xref linkend="table.sl-listen"/> sur
- chaque nœud, cela vous donnera une bonne idée de l'état du réseau
- de communication. Jusqu'à ce que les <xref linkend="slon"/> démarrent,
- chaque nœud est partiellement configuré. Si le cluster contient
- deux nœuds, alors il doit y avoir deux entrées dans chacune des
- trois tables une fois que les communications sont correctement
- configurées. S'il y a moins d'entrées, vous devriez pouvoir deviner ce
- qui manque.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si nécessaire (<emphasis>c'est-à-dire</emphasis> - si votre version est
- antérieure à la version 1.1), lancez des requêtes <xref
- linkend="stmtstorelisten"/> pour indiquer comment les nœuds
- utiliseront les voies de communications.
- </para>
-
- <para>
- Une fois que c'est fait, les traces des nœuds afficheront un niveau
- d'activité supérieur, notamment les événements produits périodiquement
- sur les différents nœuds, ainsi que leur propagation.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Configurez l'ensemble de réplication avec (<xref
- linkend="stmtcreateset"/>), ajoutez les tables avec (<xref
- linkend="stmtsetaddtable"/>), les séquences avec (<xref
- linkend="stmtsetaddsequence"/>), puis vérifiez que vous retrouvez des
- traces adéquates avec <xref linkend="logaddobjects"/> uniquement dans
- les traces du nœud d'origine de l'ensemble de réplication.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Soumettre une requête <xref linkend="stmtsubscribeset"/>, l'événement
- devrait être visible sur les deux nœuds.
- </para>
-
- <para>
- Il reste quelques actions à mener sur le nœud origine... L'abonné
- doit ensuite recevoir un événement <command>COPY_SET</command>, ce qui
- doit afficher des informations dans les traces à propos de l'ajout de
- chaque table et de la copie de leurs données. Consultez la section
- <xref linkend="logsubtime"/> pour plus de détails.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- À partir de là, vous constaterez deux types de comportements :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Sur le nœud origine, peu d'informations seront enregistrés dans
- les traces, juste des indications sur les événements <command>SYNC</command>
- générés et confirmés par les autres nœuds. Consultez la section
- <xref linkend="lognormalsync"/> pour plus d'informations sur les
- différents types de traces que vous pouvez rencontrer.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Sur le nœud abonné, vous trouverez des rapports sur les événements
- <command>SYNC</command> et sur les données que l'abonné obtient du
- fournisseur. Ceci se produit peu fréquemment si le nœud origine ne
- reçoit pas de mises à jour ; c'est au contraire très fréquent si le
- nœud origine reçoit beaucoup de modifications.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-<sect2>
-<title>Les traces et leurs implications</title>
-
-<para>
- Cette section énumère les nombreux messages d'erreurs que l'on peut trouver
- dans les traces de &slony1;, ainsi qu'une brève explication de leur
- implication. Il s'agit d'une liste relativement compréhensible, qui omet
- simplement certains messages de niveau <command>DEBUG4</command> qui sont
- presque toujours inintéressants.
-</para>
-
-<sect3 id="logshiplog">
-<title>Traces associées au Log Shipping</title>
-
-<para>
- La plupart de ces messages concernent des erreurs qui se produisent lorsque
- le mécanisme de <xref linkend="logshipping"/> échoue. En général, cela se
- produit si le système de fichiers utilisé pour le log shipping est plein ou
- si les droits d'un répertoire sont mal définies.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: log archive failed %s - %s\n</command>
- </para>
-
- <para>
- Ce message indique qu'une erreur a été rencontrée en essayent d'écrire
- un fichier de log shipping. Normalement, le démon &lslon; essaie à
- nouveau jusqu'à ce qu'il réussisse.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: writing archive log...</command>
- </para>
-
- <para>
- Ce message indique qu'un fichier d'archive est écrit pour un ensemble de
- <command>SYNC</command> particulier.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>INFO: remoteWorkerThread_%d: Run Archive Command %s</command>
- </para>
-
- <para>
- Si &lslon; est configuré (avec l'option <option>-x</option>, c'est-à-dire
- <envar>command_on_logarchive</envar>) pour lancer une commande après
- chaque génération de fichier d'archive, ce message indique quand cette
- commande est effectuée via la fonction <function>system()</function>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: Could not open COPY SET archive file %s - %s</command>
- </para>
-
- <para>
- Ce message semble assez explicite...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: Could not generate COPY SET archive header %s - %s</command>
- </para>
-
- <para>
- Ce message signifie probablement que vous avez saturé le système de fichier...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR remoteWorkerThread_%d: "update "_slony_regress1".sl_archive_counter set ac_num = ac_num + 1, ac_timestamp = CURRENT_TIMESTAMP; select ac_num, ac_timestamp from "_slony_regress1".sl_archive_counter; " PGRES_FATAL_ERROR ERROR: could not serialize access due to concurrent update</command>
- </para>
-
- <para>
- Ce message se produit occasionnellement lorsqu'on utilise le log
- shipping ; il se produit généralement lorsque que le cluster
- contient trois nœuds ou plus, et que le démon tente d'exécuter
- simultanément des événements en provenance de différents nœuds.
- Ceci ne représente pas un problème sérieux ; &slony1; tentera à
- nouveau de traiter l'événement qui a échoué, sans que l'intervention
- d'un administrateur ne soit nécessaire.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-<sect3 id="ddllogs">
-<title>Traces à propose des scripts DDL</title>
-
-<para>
- La gestion des ordres DDL est un peu fragile, comme indiqué dans la section
- <xref linkend="ddlchanges"/> ; voici des messages à caractère informatif
- et des messages d'erreur qui se produisent lors de l'exécution d'une requête
- <xref linkend="stmtddlscript"/>.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: DDL préparation failed - set %d - only on node %</command>
- </para>
-
- <para>
- Quelque chose s'est cassé lors du traitement d'un script DDL sur un des
- nœuds. Ceci indique probablement que le schéma du nœud était
- différent de celui du nœud origine ; vous devez probablement
- effectuer une modification à la main sur ce nœud pour que
- l'événement puisse être traité. Une alternative très regrettable consiste
- à supprimer l'événement bloquant, sachant qu'il est possible que cette
- suppression ne fonctionne pas...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>SLON_CONFIG: remoteWorkerThread_%d: DDL request with %d statements</command>
- </para>
-
- <para>
- Ce message est informatif, il indique combien de commandes SQL ont été traitées.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>SLON_ERROR: remoteWorkerThread_%d: DDL had invalid number of statements - %d</command>
- </para>
-
- <para>
- Ce message se produit lorsque le nombre de commandes traitées est
- inférieure à 0 (ce qui est théoriquement impossible) ou supérieure à
- MAXSTATEMENTS. Ceci indique que le script DDL est probablement mal
- écrit...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: malloc() failure in DDL_SCRIPT - could not allocate %d bytes of memory</command>
- </para>
-
- <para>
- Ceci se produit uniquement si vous soumettez un script DDL
- extraordinairement long, qui sature la mémoire allouée à &lslon;
- (« out of memory »).
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>CONFIG: remoteWorkerThread_%d: DDL Statement %d: [%s]</command>
- </para>
-
- <para>
- Ce message fait la liste de tous les ordres DDL au fur et à mesure qu'ils
- sont soumis.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: DDL Statement failed - %s</command>
- </para>
-
- <para>
- Un des ordres DDL a fonctionné sur le nœud origine mais il a
- échoué sur le nœud local...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>CONFIG: DDL Statement success - %s</command>
- </para>
-
- <para>
- Tout va bien...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: Could not generate DDL archive tracker %s - %s</command>
- </para>
-
- <para>
- Apparemment, le script DDL ne peut pas être écrit dans le fichier de log
- shipping...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: Could not submit DDL script %s - %s</command>
- </para>
-
- <para>
- Le script ne peut pas être écrit dans un fichier de log shipping.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: Could not close DDL script %s - %s</command>
- </para>
-
- <para>
- Impossible de fermer un fichier de log shipping contenant un script DDL.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I ddlScript_prepare(): set % not found</command>
- </para>
-
- <para>
- L'ensemble de réplication est introuvable sur ce nœud; Vous avez
- probablement spécifié un mauvais identifiant de nœud...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I ddlScript_prepare_int(): set % not found</command>
- </para>
-
- <para>
- L'ensemble de réplication est introuvable sur ce nœud. Vous avez
- probablement spécifié un mauvais identifiant de nœud...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: alterTableForReplication(): Table with id % not found</command>
- </para>
-
- <para>
- Apparemment, la table n'a pas été trouvée. Le schéma est peut-être erroné ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: alterTableForReplication(): Table % is already in altered state</command>
- </para>
-
- <para>
- Curieux... Le script tente de répliquer une table une
- <emphasis>seconde</emphasis> fois ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: alterTableRestore(): Table with id % not found</command>
- </para>
-
- <para>
- Ce message se produit lorsqu'une table est en cours de restauration vers
- un état <quote>non-repliqué</quote> ; apparemment, la table
- répliquée n'a pas été trouvée.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: alterTableRestore(): Table % is not in altered state</command>
- </para>
-
- <para>
- La table n'est pas dans un état répliqué. Cela ne devrait pas se produire
- si la réplication fonctionne correctement...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>NOTICE: Slony-I: alterTableForReplication(): multiple instances of trigger % on table %'',</command>
- </para>
-
- <para>
- Ceci se produit en général lorsque vous avez une table avec des triggers
- que la réplication a dû cacher lors de l'abonnement du nœud et que
- vous avez ajouté un triggrer portant le même nom. Maintenant, lorsque l'on
- tente de réactiver le trigger caché, les deux triggers entrent en conflit.
- </para>
-
- <para>
- Le script DDL continuera a tourner, encore et encore, ou la commande
- UNINSTALL NODE échouera, jusqu'à ce que vous supprimiez le trigger
- <quote>visible</quote> à la main puisque vous l'avez probablement ajouté
- à la main un peu plus tôt.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: Unable to disable triggers</command>
- </para>
-
- <para>
- Cette erreur se produit à la suite du problème de <quote>triggers
- multiples</quote>.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-<sect3>
-<title>Problèmes avec les processus</title>
-
-<para>
- Le modèle de gestion des processus ("threading") de &slony1; n'est pas
- directement <quote>paramétrable par les utilisateurs</quote>. Chaque démon
- &lslon; crée un ensemble pré-défini de processus pour gérer les différentes
- connexions nécessaires. La seule occasion où la gestion des processus peut
- poser problème est lorsque les bibliothèques de &postgres; n'ont pas été
- compilées <quote>correctement</quote>, auquel cas il sera de toute façon
- impossible de compiler &slony1;.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <command>FATAL: remoteWorkerThread_%d: pthread_create() - %s</command>
- </para>
-
- <para>
- Impossible de créer un nouveau processus de traitement des événements distants.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1 remoteWorkerThread_%d: helper thread for provider %d created</command>
- </para>
-
- <para>
- Ceci se produit en général lorsque le démon &lslon; démarre : un
- processus est créé pour chaque nœud que le nœud local doit
- écouter.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1: remoteWorkerThread_%d: helper thread for provider %d terminated </command>
- </para>
-
- <para>
- Si un abonnement est modifié et qu'un nœud n'est plus un nœud
- fournisseur, alors le processus qui traite les événements sur ce
- nœud peut être arrêté.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1: remoteWorkerThread_%d: disconnecting from data provider %d</command>
- </para>
-
- <para>
- Un nœud fournisseur qui n'est plus utilisé peut être supprimé ;
- si les informations de connexion sont changées, le démon &lslon; doit se
- déconnecter et se reconnecter.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: ignore new events due to shutdown</command>
- </para>
-
- <para>
- Si le démon &lslon; est en cours d'arrêt, il est futile de traiter d'autres événements.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1: remoteWorkerThread_%d: node %d - no worker thread</command>
- </para>
-
- <para>
- Curieux : il est impossible de réveiller le processus de
- traitement ; pourtant il devrait déjà y en avoir un...
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-<sect3 id="logsubtime">
-<title>Traces au moment d'un abonnement</title>
-
-<para>
- Un abonnement est une opération très spéciale pour &slony1;. Si vous avez un
- grand volume de données à copier sur l'abonné, cela peut prendre un temps
- considérable. &slony1; enregistre une quantité considérable d'informations
- lors de ce processus, qui sera probablement très utile aux utilisateurs. En
- particulier, il produit des traces à chaque fois qu'il commence et termine
- la copie des données d'une table et lorsqu'il finit l'indexation de la table.
- Cela ne rend pas un abonnement de 28 heures plus rapide, mais au moins cela
- vous aide à suivre son déroulement.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <command>DEBUG1: copy_set %d</command>
- </para>
-
- <para>
- Ceci indique le départ de la copie de données pour un nouvel abonnement.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: set %d not found in runtime configuration </command>
- </para>
-
- <para>
- &lslon; a tenté de lancer un abonnement ; il n'a pas trouvé les
- informations de connexion à la source des données. Peut-être que les
- chemins ne sont pas correctement propagés ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: node %d has no pa_conninfo</command>
- </para>
-
- <para>
- Apparemment, les informations de connexion sont
- <emphasis>fausses</emphasis>...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: copy set %d cannot connect to provider DB node %d</command>
- </para>
-
- <para>
- &lslon; n'a pas pu se connecter au fournisseur. Est-ce que les
- informations de connexion sont fausses ? Peut-être que
- l'authentification est mal configurée ? Peut-être que la base de
- donnée ne fonctionne pas ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1: remoteWorkerThread_%d: connected to provider DB</command>
- </para>
-
- <para>
- Excellent : le processus de copie a pu se connecter au fournisseur.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: sequenceSetValue(): sequence % not found</command>
- </para>
-
- <para>
- Curieux ; la séquence de l'objet est absente. Est-ce que quelqu'un
- l'a supprimé à la main du schéma ? (<emphasis>c'est-à-dire</emphasis>
- sans utiliser <xref linkend="stmtddlscript"/>)
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: subscribeSet() must be called on provider</command>
- </para>
-
- <para>
- Cette fonction devrait être appelée sur le nœud fournisseur.
- Normalement, &lslonik; gère correctement ce cas, à moins qu'il y ait de
- mauvais DSN dans un script &lslonik;...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: subscribeSet(): set % not found</command>
- </para>
-
- <para>
- Le nœud fournisseur ne connaît pas cet ensemble de réplication.
- Un mauvais paramètre dans un script &lslonik; ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: subscribeSet(): set origin and receiver cannot be identical</command>
- </para>
-
- <para>
- Un nœud origine ne peut pas être abonné à lui-même.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: subscribeSet(): set provider and receiver cannot be identical</command>
- </para>
-
- <para>
- Un nœud récepteur doit s'abonner à un nœud
- <emphasis>différent</emphasis>...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>Slony-I: subscribeSet(): provider % is not an active forwarding node for replication set %</command>
- </para>
-
- <para>
- Vous devez utiliser un nœud fournisseur actif et en cours de
- fonctionnement comme source des données.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>Slony-I: subscribeSet_int(): set % is not active, cannot change provider</command>
- </para>
-
- <para>
- Vous ne pouvez pas changer le fournisseur pour le moment...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>Slony-I: subscribeSet_int(): set % not found</command>
- </para>
-
- <para>
- Ce nœud ne connaît pas l'ensemble de réplication... Vous avez
- peut-être soumis un mauvais paramètre ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>Slony-I: unsubscribeSet() must be called on receiver</command>
- </para>
-
- <para>
- Cela parait trivial... Ceci indique probablement un mauvais DSN &lslonik;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>Slony-I: Cannot unsubscribe set % while being provider</command>
- </para>
-
- <para>
- Cela semble évident ; <xref linkend="stmtunsubscribeset"/> va
- échouer si un nœud est dépendant des abonnés dont il est le
- fournisseur.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>Slony-I: cleanupEvent(): Single node - deleting events < %</command>
- </para>
-
- <para>
- S'il n'y a qu'un seul nœud, l'événement de nettoyage va supprimer
- les anciens événements afin de ne pas récupérer le <quote>crud</quote>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>Slony-I: tableAddKey(): table % not found</command>
- </para>
-
- <para>
- Peut-être que vous n'avez pas copié le schéma proprement ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>Slony-I: tableDropKey(): table with ID% not found</command>
- </para>
-
- <para>
- Cela paraît curieux ; cette table est probablement déjà en cours de
- réplication ; il est donc étrange que cette table ait disparue.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>Slony-I: determineIdxnameUnique(): table % not found</command>
- </para>
-
- <para>
- Avez-vous correctement copié le schéma sur le nouveau nœud ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>Slony-I: table % has no primary key</command>
- </para>
-
- <para>
- Ceci signifie probablement que le chargement du schéma s'est mal passé...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>Slony-I: table % has no unique index %</command>
- </para>
-
- <para>
- Ceci signifie probablement que le chargement du schéma s'est mal passé...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>WARN: remoteWorkerThread_%d: transactions earlier than XID %s are still in progress</command>
- </para>
-
- <para>
- Ceci indique qu'une vieille transaction est en cours d'exécution et
- qu'elle a débutée avant le plus vieil événement <command>SYNC</command>
- disponible sur le fournisseur. &slony1; ne peut pas lancer une réplication
- tant que cette transaction n'est pas achevée. Ce message sera répété
- jusqu'à ce que la transaction aboutisse...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: prepare to copy table %s</command>
- </para>
-
- <para>
- Ceci indique que &lslon; commence les préparatifs pour mettre en place un
- abonnement pour une table.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1: remoteWorkerThread_%d: table %s will require Slony-I serial key</command>
- </para>
-
- <para>
- Évidemment, cette table est définie avec <xref linkend="stmttableaddkey"/>
- et &slony1; a ajouté une clef primaire supplémentaire.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: Could not lock table %s on subscriber</command>
- </para>
-
- <para>
- Pour une certaine raison, la table ne peut pas être verrouillée, donc la
- réplication doit être redémarrée. Si le problème concerne un inter-blocage
- (« deadlock »), essayer la commande à nouveau peut fonctionner.
- S'il s'agit d'un autre problème, vous devez intervenir...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: all tables for set %d found on subscriber</command>
- </para>
-
- <para>
- Ce message d'information indique que lors du premier passage sur les tables,
- aucun problème n'a été trouvé...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: copy sequence %s</command>
- </para>
-
- <para>
- Ce message indique qu'une séquence est traitée...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: copy table %s</command>
- </para>
-
- <para>
- &lslon; commence la copie d'une table...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG3: remoteWorkerThread_%d: table %s Slony-I serial key added local</command>
- </para>
-
- <para>
- Une nouvelle colonne vient d'être ajoutée dans la table afin qu'elle
- dispose d'une clef primaire.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG3: remoteWorkerThread_%d: local table %s already has Slony-I serial key</command>
- </para>
-
- <para>
- Il n'est pas nécessaire d'ajouter une clef de type 'serial' ;
- apparemment, elle existe déjà.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG3: remoteWorkerThread_%d: table %s does not require Slony-I serial key</command>
- </para>
-
- <para>
- Apparemment, cette table n'a pas besoin d'une clef primaire supplémentaire...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG3: remoteWorkerThread_%d: table %s Slony-I serial key added local</command>
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: Begin COPY of table %s</command>
- </para>
-
- <para>
- &lslon; va lancer la commande COPY des deux côtés pour copier la table...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: Could not generate copy_set request for %s - %s</command>
- </para>
-
- <para>
- Ceci indique que la requête <command>delete/copy</command> a échouée sur
- l'abonné. Le &lslon; va répéter la tentative de
- <command>COPY_SET</command> ; il est probable que l'opération continue
- d'échouer...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: copy to stdout on provider - %s %s</command>
- </para>
-
- <para>
- Évidemment, quelque chose ne fonctionne pas au niveau de l'opération
- COPY vers la sortie <filename>stdout</filename> sur le nœud
- fournisseur... l'événement va être lancé à nouveau...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: copy from stdin on local node - %s %s</command>
- </para>
-
- <para>
- Évidemment, quelque chose n'a pas fonctionné lors de l'opération COPY
- dans la table sur le nœud abonné... L'événement va être lancé à
- nouveau...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: %d bytes copied for table %s</command>
- </para>
-
- <para>
- Ce message indique que l'opération COPY sur la table est achevée. Ceci
- est suivi d'un <command>ANALYZE</command> et d'une réindexation de la
- table sur l'abonné.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: %.3f seconds to copy table %s</command>
- </para>
-
- <para>
- Après ce message, la copie, la réindexation et l'analyse sont terminées sur l'abonné.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: set last_value of sequence %s (%s) to %s</command>
- </para>
-
- <para>
- Sans surprise, cela indique qu'une séquence a été traitée sur l'abonnée.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: %.3 seconds to copy sequences</command>
- </para>
-
- <para>
- Ce message indique le temps passé pour le traitement de l'événement
- <command>COPY_SET</command>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: query %s did not return a result</command>
- </para>
-
- <para>
- Ceci indique qu'une requête, exécutée lors du traitement final de
- l'événement <command>COPY_SET</command>, a échoué. La copie est
- redémarrée...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: copy_set no previous SYNC found, use enable event</command>
- </para>
-
- <para>
- Ceci se produit si aucun événement SYNC n'a été trouvé ; l'événement
- courant est positionné au niveau de l'événement
- <command>ENABLE_SUBSCRIPTION</command>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: copy_set SYNC found, use event seqno %s</command>
- </para>
-
- <para>
- Ceci se produit si un événement SYNC est trouvé ; l'événement
- courant est positionné à la valeur indiquée.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: sl_setsync entry for set %d not found on provider</command>
- </para>
-
- <para>
- Une information de synchronisation était attendue en provenance d'un
- nœud abonné existant, mais elle n'a pas été trouvée. Il s'agit
- probablement d'une erreur capable de bloquer la réplication...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1: remoteWorkerThread_%d: could not insert to sl_setsync_offline</command>
- </para>
-
- <para>
- Après la configuration d'un abonné et presque tout est en place, des
- écritures dans un fichier de log shipping ont échouées. Peut-être que
- le disque est plein...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1: remoteWorkerThread_%d: %.3f seconds to build initial setsync status</command>
- </para>
-
- <para>
- Ce message indique le temps total nécessaire pour que l'événement copy_set
- soit réalisé...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1: remoteWorkerThread_%d: disconnected from provider DB</command>
- </para>
-
- <para>
- À la fin d'un événement d'abonnement, le &lslon; de l'abonné va se
- déconnecter du fournisseur et supprimer les connexions...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1: remoteWorkerThread_%d: copy_set %d done in %.3f seconds</command>
- </para>
-
- <para>
- Ce message indique le temps total nécessaire pour effectuer la commande
- copy_set... c'est le signe d'un abonné réussi !
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1: remoteWorkerThread_%d: copy_set %d done in %.3f seconds</command>
- </para>
-
- <para>
- Ce message indique le temps total nécessaire pour effectuer la commande
- copy_set... c'est le signe d'un abonné réussi !
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-<sect3 id="logmergeset">
-<title>Messages associés à la commande MERGE SET</title>
-
-<para>
- Diverses exceptions peuvent conduire au rejet d'un <xref
- linkend="stmtmergeset"/> ; ces problèmes doivent être réglés avant de
- soumettre à nouveau la requête.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <command>ERROR: Slony-I: merged set ids cannot be identical</command>
- </para>
-
- <para>
- Il est illogique d'essayer de fusionner un ensemble avec lui-même.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: set % not found </command>
- </para>
-
- <para>
- Un ensemble absent ne peut pas être fusionné.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: set % does not originate on local node</command>
- </para>
-
- <para>
- La requête <xref linkend="stmtmergeset"/> doit être envoyée au nœud
- origine des ensembles qu'il faut fusionner.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: subscriber lists of set % and % are different</command>
- </para>
-
- <para>
- Les ensembles ne peuvent être fusionné que s'ils ont la même liste d'abonnés.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: set % has subscriptions in progress - cannot merge</command>
- </para>
-
- <para>
- <xref linkend="stmtmergeset"/> ne peut pas fusionner tant que tous les
- abonnements ne sont pas achevés. Si ce message apparaît, cela signifie
- que les listes d'abonnées sont identiques mais qu'un ou plusieurs
- nœuds n'ont pas terminé leur processus d'abonnement. Il est
- probable qu'attendre une courte période avant de soumettre à nouveau la
- requête <xref linkend="stmtmergeset"/> suffise à régler le problème.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-<sect3 id="lognormalsync">
-<title>Traces associés l'activité normale des SYNC</title>
-
-<para>
- Certains de ces messages indiquent des erreurs mais,
- <quote>normalement</quote>, ils présentent les informations attendues
- lorsque la réplication fonctionne correctement.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: forward confirm %d,%s received by %d</command>
- </para>
-
- <para>
- Ces événements devraient apparaître fréquemment et suivant une certaine
- routine, car ils témoignent des confirmations d'événements qui sont
- reçues.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1: remoteWorkerThread_%d: SYNC %d processing</command>
- </para>
-
- <para>
- Ce message indique le début du traitement d'un <command>SYNC</command>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: No pa_conninfo for data provider %d</command>
- </para>
-
- <para>
- Les informations de connexion au fournisseur ne sont pas disponibles.
- Normalement, cela n'est pas possible...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteListenThread_%d: timeout for event selection</command>
- </para>
-
- <para>
- Ce message signifie que le processus d'écoute
- (<filename>src/slon/remote_listener.c</filename>) s'est arrêté après
- avoir tenté de déterminer quels événements étaient en attente.
- </para>
-
- <para>
- Ceci se produit lorsqu'une connexion réseau est coupée. Si c'est le cas,
- redémarrer le démon &lslon; devrait suffire à résoudre le problème.
- </para>
-
- <para>
- Par ailleurs, ceci peut se produire lorsque le démon &lslon; de ce
- nœud a été en panne pendant longtemps, et qu'il y a une quantité
- énorme de lignes dans la table <envar>sl_event</envar> sur ce nœud
- ou sur d'autres, en attente d'être traitées et qu'il faut plus de <xref
- linkend="slon-config-remote-listen-timeout"/> secondes pour exécuter la
- requête SQL. Dans les anciennes version de &slony1;, ce paramètre de
- configuration n'existait pas ; le temps maximum était fixé à 300
- secondes. Dans les nouvelles versions, vous pouvez augmenter cette valeur
- dans le fichier de configuration de &lslon; pour que le démon continue à
- traiter les événements. Puis vous pourrez enquêter pour découvrir
- pourquoi personne ne surveillait le processus et pourquoi la réplication
- a été rompue pendant aussi longtemps...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: cannot connect to data provider %d on 'dsn'</command>
- </para>
-
- <para>
- Nous n'avons pas les informations de connexions
- <emphasis>correctes</emphasis> pour nous connecter au fournisseur de
- données.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1: remoteWorkerThread_%d: connected to data provider %d on 'dsn'</command>
- </para>
-
- <para>
- Excellent ; le démon &lslon; s'est connecté au fournisseur.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>WARN: remoteWorkerThread_%d: don't know what ev_seqno node %d confirmed for ev_origin %d</command>
- </para>
-
- <para>
- Il n'y a aucune information de confirmation en provenance de ce
- fournisseur ; il faut annuler le <command>SYNC</command> et attendre
- en espérant que cette information arrive rapidement...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1: remoteWorkerThread_%d: data provider %d only confirmed up to ev_seqno %d for ev_origin %d </command>
- </para>
-
- <para>
- Le fournisseur de ce nœud est un abonné. Apparemment, cet abonné
- est en retard. Le démon &lslon; doit attendre que le fournisseur rattrape
- son retard avant de recevoir de <emphasis> nouvelles</emphasis> données.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: data provider %d confirmed up to ev_seqno %s for ev_origin %d - OK</command>
- </para>
-
- <para>
- Très bien ; le fournisseur dispose des données dont l'abonné a besoin...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: syncing set %d with %d table(s) from provider %d</command>
- </para>
-
- <para>
- Ce message indique les plans d'actions d'un <command>SYNC</command> :
- il y a un ensemble de tables à traiter.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: ssy_action_list value: %s length: %d</command>
- </para>
-
- <para>
- Cette partie de la requête a collecté des données qui semblent être
- <quote>volumineuses</quote> ; ce message indique comment elles ont
- été compressées...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: Didn't add OR to provider</command>
- </para>
-
- <para>
- Ce message indique qu'il n'y avait rien dans une clause
- <quote>fournisseur</quote> à l'intérieur de la requête qui collecte les
- données à appliquer, ce qui ne devrait pas se produire. Il est probable
- que les choses aient mal tournées quelque part...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: no sets need syncing for this event</command>
- </para>
-
- <para>
- Ceci se produira pour tous les événements <command>SYNC</command> générés
- sur les nœuds qui ne sont pas l'origine d'un ensemble de
- réplication. Vous pouvez vous attendre à voir ces messages assez
- fréquemment.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG3: remoteWorkerThread_%d: activate helper %d</command>
- </para>
-
- <para>
- Un processus va être lancé pour aider à traiter les données de l'événement
- <command>SYNC</command>...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG4: remoteWorkerThread_%d: waiting for log data</command>
- </para>
-
- <para>
- Le processus attend que les données se consument (c'est-à-dire qu'elles
- soient appliquées sur le réplicat).
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: %s %s - qualification was %s</command>
- </para>
-
- <para>
- Apparemment, l'application de données répliquées sur l'abonné a échoué....
- ceci indique très certainement une corruption assez grave.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: replication query did not affect one row (cmdTuples = %s) - query was: %s qualification was: %s</command>
- </para>
-
- <para>
- Si <envar>SLON_CHECK_CMDTUPLES</envar> est défini, &lslon; applique les
- changements ligne par ligne, et vérifie que chaque changement affecte
- exactement une ligne. Apparemment, ce n'était pas le cas ici, ce qui
- semble indiquer une corruption de la réplication. C'est plutôt une
- mauvaise nouvelle...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: SYNC aborted</command>
- </para>
-
- <para>
- Le <command>SYNC</command> a été annulé. Le &lslon; va probablement
- tenter de nouveau ce <command>SYNC</command> dans quelque temps. Si le
- <command>SYNC</command> échoue encore et toujours, il y un problème
- récurrent et la réplication ne va probablement pas reprendre sans une
- intervention. Il est peut-être nécessaire de désabonner/réabonner
- l'ensemble de réplication concerné, ou si il n'y a qu'un seul ensemble
- de réplication sur le nœud esclave, il est parfois plus simple de
- supprimer et de recréer le nœud. Si les connexions de l'application
- peuvent être détournées vers le nœud maître pendant cette opération,
- alors il n'est pas nécessaire d'arrêter le service.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: new sl_rowid_seq value: %s</command>
- </para>
-
- <para>
- Ce message rend compte de la progression de cette séquence interne de
- &slony1;.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: SYNC %d done in %.3f seconds</command>
- </para>
-
- <para>
- Ce message indique qu'un <command>SYNC</command> s'est achevé correctement.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG1: remoteWorkerThread_%d_d:%.3f seconds delay for first row </command>
- </para>
-
- <para>
- Ce message indique combien de temps il a fallu pour récupérer la première
- ligne du curseur LOG qui lit les données dans les tables sl_log tables.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d_d: large log_cmddata for actionseq %s not found</command>
- </para>
-
- <para>
- &lslon; n'a pas trouvé les données relatives à une <quote>très
- grande</quote> ligne de la table sl_log qui a été récupéré
- individuellement. Ceci ne devrait pas se produire.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d_d:%.3f seconds until close cursor</command>
- </para>
-
- <para>
- Ceci indique combien de temps il a fallu pour lire les données dans le
- curseur LOG qui extrait les données des tables sl_log.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d_d: inserts=%d updates=%d deletes=%d</command>
- </para>
-
- <para>
- Ce message montre l'activité enregistrée dans le <command>SYNC</command>
- courant.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG3: remoteWorkerThread_%d: compress_actionseq(list,subquery) Action list: %s</command>
- </para>
-
- <para>
- Ce message indique qu'une partie de la requête du curseur LOG va être
- compressée. (Dans certains cas, les requêtes peuvent grossir jusqu'à
- une taille <emphasis>énorme</emphasis> et faire exploser l'analyseur
- de requêtes...).
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG3: remoteWorkerThread_%d: compressed actionseq subquery %s</command>
- </para>
-
- <para>
- Ce message indique comment la sous-requête a été compressée.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-<sect3 id="logaddobjects">
-<title>Traces concernant l'ajout d'objets dans des ensembles de réplication</title>
-
-<para>
- Ces messages apparaîtront dans les traces d'un nœud origine au moment
- où vous configurerez un ensemble de réplication ; certains apparaîtront
- sur les nœuds abonnés lors de leur abonnement.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <command>ERROR: Slony-I: setAddTable_int(): table % has no index %</command>
- </para>
-
- <para>
- Apparemment, l'index de clé étrangère spécifié est absent sur ce
- nœud...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setAddTable_int(): table % not found</command>
- </para>
-
- <para>
- La table n'a pas été trouvé sur ce nœud ; avez-vous chargé
- correctement le schéma ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setAddTable_int(): table % is not a regular table</command>
- </para>
-
- <para>
- Vous avez tenté de répliquer quelque chose qui n'est pas dans la
- table ; vous ne pouvez pas faire ça !
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>NOTICE: Slony-I setAddTable_int(): table % PK column % nullable</command>
- </para>
-
- <para>
- Vous avez tenté de répliquer une table dont une colonne de la clef
- primaire candidate peut être NULL. Toutes les colonnes participant à
- une clef primaire doivent être <command>NOT NULL</command>. Cette
- requête va échouer.
- </para>
-
- <para>
- Une vérification de cette condition fut introduit dans la version 1.2 de
- &slony1;. Si vous avez un réplicat 1.1, il va continuer à fonctionner
- après la mise à jour en 1.2 mais vous rencontrerez ce message lorsque
- vous essaierez d'ajouter de nouveaux abonnés.
- </para>
-
- <para>
- Vous pouvez chercher des combinaisons table/index ayant des colonnes
- pouvant être NULL sur un nœud existant avec la requête
- suivante :
- <screen>select c.relname as table_name, ic.relname as index_name, att.attname, att2.attnotnull
-from _cluster.sl_table t, pg_catalog.pg_class c, pg_index i, pg_catalog.pg_class ic, pg_catalog.pg_attribute att, pg_catalog.pg_attribute att2
-where t.tab_reloid = c.oid
-and t.tab_idxname = ic.relname
-and ic.oid = i.indexrelid
-and att.attrelid = i.indexrelid
-and att2.attname = att.attname
-and att2.attrelid = c.oid
-and att2.attnotnull = 'f';</screen>
- </para>
-
- <para>
- Ces cas peuvent être rectifiés en exécutant à chaque fois une requête du
- type :
- <command>alter table matable alter column nullablecol set not null;</command>
- Lancée sur un abonné ayant une table vide, cette requête s'exécutera très
- rapidement. Elle prendra plus de temps sur une table qui contient déjà
- beaucoup de données car la modification nécessite un parcours de la table
- pour vérifier qu'il n'existe aucune ligne ayant la valeur NULL dans la
- colonne.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setAddTable_int(): table % not replicable!</command>
- </para>
-
- <para>
- Ceci se produit à cause d'une colonne qui n'est pas NOT NULL dans une
- clef primaire.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setAddTable_int(): table id % has already been assigned!</command>
- </para>
-
- <para>
- L'identifiant de la table doit être assigné de manière unique dans <xref
- linkend="stmtsetaddtable"/> ; apparemment, vous avez demandé une
- valeur qui est déjà utilisée.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setAddSequence(): set % not found</command>
- </para>
-
- <para>
- Apparemment, l'ensemble que vous demandez n'est pas disponible...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setAddSequence(): set % has remote origin</command>
- </para>
-
- <para>
- Vous pouvez uniquement ajouter des objets sur le nœud origine.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setAddSequence(): cannot add sequence to currently subscribed set %</command>
- </para>
-
- <para>
- Apparemment, l'ensemble de réplication que vous demandez a déjà été
- abonné. Vous ne pouvez pas ajouter des tables/séquences dans un ensemble
- qui a déjà des abonnés. Vous devez créer un nouvel ensemble, y ajouter
- des objets et définir ses abonnements
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setAddSequence_int(): set % not found</command>
- </para>
-
- <para>
- Apparemment, l'ensemble que vous demandez n'est pas disponible...
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setAddSequence_int(): sequence % not found</command>
- </para>
-
- <para>
- Apparemment, la séquence que vous demandez n'est pas disponible sur ce
- nœud. Comment avez-vous mis en place le schéma sur les nœuds
- abonnés ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setAddSequence_int(): % is not a sequence</command>
- </para>
-
- <para>
- Ce message est assez évident.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setAddSequence_int(): sequence ID % has already been assigned</command>
- </para>
-
- <para>
- Chaque identifiant de séquence ajouté doit être unique. Apparemment, vous
- avez réutilisé un identifiant déjà existant.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-<sect3>
-<title>Traces lors du déplacement d'un objet d'un ensemble vers un autre</title>
-
-<itemizedlist>
- <listitem>
- <para>
- <command>ERROR: Slony-I setMoveTable_int(): table % not found</command>
- </para>
-
- <para>
- La table n'a pas été trouvée sur ce nœud ; vous avez
- probablement indiqué le mauvais identifiant.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setMoveTable_int(): set ids cannot be identical</command>
- </para>
-
- <para>
- Quel est l'intérêt de déplacer une table dans un ensemble où elle se
- trouve déjà ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setMoveTable_int(): set % not found</command>
- </para>
-
- <para>
- L'ensemble n'a pas été trouvé sur le nœud ; vous avez
- probablement indiqué un mauvais identifiant.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setMoveTable_int(): set % does not originate on local node</command>
- </para>
-
- <para>
- L'ensemble n'est pas originaire de ce nœud ; vous avez
- probablement indiqué le mauvais EVENT NODE.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setMoveTable_int(): subscriber lists of set % and % are different</command>
- </para>
-
- <para>
- Vous pouvez uniquement déplacer les objets entre des ensembles qui ont
- la même liste d'abonnés.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setMoveSequence_int(): sequence % not found</command>
- </para>
-
- <para>
- La séquence n'a pas été trouvée sur ce nœud ; vous avez
- probablement indiqué un mauvais identifiant.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setMoveSequence_int(): set ids cannot be identical</command>
- </para>
-
- <para>
- Quel est l'intérêt de déplacer une séquence dans un ensemble où elle se
- trouve déjà ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setMoveSequence_int(): set % not found</command>
- </para>
-
- <para>
- L'ensemble n'a pas été trouvé sur le nœud ; vous avez
- probablement indiqué un mauvais identifiant.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setMoveSequence_int(): set % does not originate on local node</command>
- </para>
-
- <para>
- L'ensemble n'est pas originaire de ce nœud ; vous avez
- probablement indiqué le mauvais EVENT NODE.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setMoveSequence_int(): subscriber lists of set % and % are different</command>
- </para>
-
- <para>
- Vous pouvez uniquement déplacer les objets entre des ensembles qui ont la
- même liste d'abonnés.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-<sect3>
-<title>Problèmes lors de la suppression d'objets</title>
-
-<itemizedlist>
- <listitem>
- <para>
- <command>ERROR: Slony-I setDropTable(): table % not found</command>
- </para>
-
- <para>
- La table n'a pas été trouvée sur ce nœud. Êtes-vous sûr d'avoir
- indiqué le bon identifiant ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setDropTable(): set % not found</command>
- </para>
-
- <para>
- L'ensemble de réplication n'a pas été trouvé sur ce nœud.
- Êtes-vous sûre d'avoir indiqué le bon identifiant ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setDropTable(): set % has remote origin</command>
- </para>
-
- <para>
- L'ensemble de réplication n'a pas ce nœud pour origine. Vous
- devez probablement spécifier le paramètre <command>EVENT NODE</command>
- dans la commande <xref linkend="stmtsetdroptable"/>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setDropSequence_int(): sequence % not found</command>
- </para>
-
- <para>
- Est-ce que cette séquence ne se trouverait pas plutôt dans un autre
- ensemble ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setDropSequence_int(): set % not found</command>
- </para>
-
- <para>
- Avez-vous spécifié le bon identifiant d'ensemble de réplication ?
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I setDropSequence_int(): set % has origin at another node - submit this to that node</command>
- </para>
-
- <para>
- Ce message semble assez évident.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-<sect3>
-<title>Problèmes lors de MOVE SET, FAILOVER, DROP NODE</title>
-
-<para>
- Beaucoup de ces erreurs se produiront si vous soumettez un script &lslonik;
- qui décrit une reconfiguration incompatible avec la configuration actuelle
- de votre cluster. Ceci devrait vous faire dire : <quote>Heureusement
- que &lslonik; a détecté ce problème à ma place !</quote>
-</para>
-
-<para>
- D'autres messages se produisent lorsque &lslon; s'avertit lui-même qu'il va
- s'arrêter. Tout <emphasis>devrait</emphasis> bien se passer lorsque vous le
- redémarrez car il lira la nouvelle configuration lors de son redémarrage.
-</para>
-
-<para>
- Hélas, quelques messages indiquent que <quote>quelque chose de mauvais est
- arrivé</quote>, auquel cas la solution ne sera pas nécessairement simple.
- Personne n'a dit que la réplication était facile...
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <command>ERROR: Slony-I: DROP_NODE cannot initiate on the dropped node</command>
- </para>
-
- <para>
- Vous devez préciser un paramètre EVENT NODE différent du nœud que
- vous voulez supprimer.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: Node % is still configured as a data provider</command>
- </para>
-
- <para>
- Vous ne pouvez pas supprimer un nœud qui est utilisé comme
- fournisseur de données ; vous devez remodeler les abonnements pour
- qu'aucun nœud ne soit dépendant de celui-ci.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: Node % is still origin of one or more sets</command>
- </para>
-
- <para>
- Vous ne pouvez pas supprimer un nœud si c'est l'origine d'un
- ensemble de réplication ! Utilisez d'abord <xref
- linkend="stmtmoveset"/> ou <xref linkend="stmtfailover"/>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: cannot failover - node % has no path to the backup node</command>
- </para>
-
- <para>
- Vous ne pouvez pas effectuer une bascule d'urgence vers un nœud qui
- n'est pas connecté à tous les abonnés, au moins indirectement.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: cannot failover - node % is not subscribed to set %</command>
- </para>
-
- <para>
- Vous ne pouvez pas faire une bascule d'urgence vers un nœud qui
- n'est pas abonné à tous les ensembles de réplication essentiels.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: cannot failover - subscription for set % is not active</command>
- </para>
-
- <para>
- Si l'abonnement a été configuré mais pas activé, la bascule d'urgence
- n'est pas possible.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: cannot failover - node % is not a forwarder of set %</command>
- </para>
-
- <para>
- Vous ne pouvez effectuer une bascule d'urgence ou une bascule contrôlée
- que vers un nœud transmetteur.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>NOTICE: failedNode: set % has no other direct receivers - move now</command>
- </para>
-
- <para>
- Si le nœud de sauvegarde est le seul abonné direct, alors la
- situation est simplifiée... Pas besoin de remodeler les abonnements !
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>NOTICE: failedNode set % has other direct receivers - change providers only</command>
- </para>
-
- <para>
- Dans ce cas, tous les abonnés directs sont redirigés vers le nœud
- de sauvegarde et le nœud de sauvegarde est redirigé vers un autre
- nœud pour qu'il puisse rattraper son retard.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>NOTICE: Slony-I: Please drop schema _ at CLUSTERNAME@</command>
- </para>
-
- <para>
- Un nœud a été désinstallé ; vous pouvez supprimer le schéma...
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-<sect3>
-<title>Permutation des traces</title>
-
-<para>
- Ces messages sont liés à la nouvelle fonctionnalité apparue dans la version
- 1.2 qui permet à &slony1; de permuter périodiquement le stockage des données
- entre <envar>sl_log_1</envar> et <envar>sl_log_2</envar>.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <command>Slony-I: Logswitch to sl_log_2 initiated'</command>
- </para>
-
- <para>
- Ce message indique que &lslon; est en train de permuter vers cette table
- de log.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>Slony-I: Logswitch to sl_log_1 initiated'</command>
- </para>
-
- <para>
- Ce message indique que &lslon; est en train de permuter vers cette table
- de log.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>Previous logswitch still in progress</command>
- </para>
-
- <para>
- Une tentative de permutation a été faite alors qu'une permutation était
- déjà en cours.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: remoteWorkerThread_%d: cannot détermine current log status</command>
- </para>
-
- <para>
- La tentative de lecture dans la table sl_log_status, qui détermine si on
- travaille sur <envar>sl_log_1</envar> ou <envar>sl_log_2</envar>, n'a
- donné aucun résultat. Ce n'est pas bon signe car il doit y avoir des
- données dans cette table... La réplication va probablement s'arrêter dans
- peu de temps.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: current local log_status is %d</command>
- </para>
-
- <para>
- Ce message indique la table (<envar>sl_log_1</envar> ou
- <envar>sl_log_2</envar>) utilisée pour stocker les données de réplication.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-<sect3>
-<title>Divers</title>
-
-<para>
- Les messages ci-dessous ne sont pas encore classés. Les auteurs de la
- documentation ont encore du travail...
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <command>ERROR: Slonik version: @MODULEVERSION@ != Slony-I version in PG build %</command>
- </para>
-
- <para>
- Ce message est produit par la fonction
- <function>checkmoduleversion()</function> lorsqu'il y a un problème de
- correspondance entre la version de &slony1; telle qu'elle est indiquée
- par &lslonik; et la version avec laquelle &postgres; a été compilé.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: registry key % is not an int4 value</command>
- </para>
-
- <para>
- Message produit par <function>registry_get_int4()</function>. Cela indique
- que la valeur demandée semble être à NULL.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: registry key % is not a text value</command>
- </para>
-
- <para>
- Message produit par <function>registry_get_text()</function>. Cela
- indique que la valeur demandée semble être à NULL.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: registry key % is not a timestamp value</command>
- </para>
-
- <para>
- Message produit par <function>registry_get_timestamp()</function>. Cela
- indique que la valeur demandée semble être à NULL.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>NOTICE: Slony-I: cleanup stale sl_nodelock entry for pid=%</command>
- </para>
-
- <para>
- Ceci se produit typiquement lorsqu'un &lslon; se lance après qu'un autre ait
- échoué ; c'est un nettoyage de routine.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: This node is already initialized</command>
- </para>
-
- <para>
- Ceci se produit typiquement lorsqu'on soumet une commande <xref
- linkend="stmtstorenode"/> sur une nœud qui a déjà été configuré
- avec le schéma &slony1;.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: node % not found</command>
- </para>
-
- <para>
- Toute tentative pour marquer un nœud non listé localement comme
- actif devrait échouer.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>ERROR: Slony-I: node % is already active</command>
- </para>
-
- <para>
- Toute tentative pour marquer un nœud déjà marqué comme actif devrait
- échouer.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG4: remoteWorkerThread_%d: added active set %d to provider %d</command>
- </para>
-
- <para>
- Indique que cet ensemble est fourni par ce fournisseur.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: event %d ignored - unknown origin</command>
- </para>
-
- <para>
- Ceci se produit probablement lorsque des événements arrivent avant
- l'événement <command>STORE_NODE</command> qui annonce que le nouveau
- nœud existe.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>WARN: remoteWorkerThread_%d: event %d ignored - origin inactive</command>
- </para>
-
- <para>
- Ceci ce produit actuellement (2007) car la désactivation d'un
- nœud n'est pas une fonctionnalité supportée.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: event %d ignored - duplicate </command>
- </para>
-
- <para>
- Ceci devrait se produire lorsqu'une notification d'événement arrive en
- provenance de deux sources.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>DEBUG2: remoteWorkerThread_%d: unknown node %d</command>
- </para>
-
- <para>
- Ceci se produit lorsque le démon &lslon; n'est conscient de l'existence
- de ce nœud. C'est probablement un signe que les requêtes
- <command>STORE_NODE</command> ne se propagent pas.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-</sect2>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/loganalysis.xml (from rev 1244, traduc/trunk/slony/loganalysis.xml)
===================================================================
--- traduc/tags/slony_1_2_12/loganalysis.xml (rev 0)
+++ traduc/tags/slony_1_2_12/loganalysis.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,2381 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="loganalysis">
+<title>Analyses des traces</title>
+<indexterm><primary>analyse des traces</primary></indexterm>
+
+<para>
+ Voici un tour d'horizon des informations que vous trouverez dans les traces
+ de &slony1;, ainsi que des explications sur leur signification.
+</para>
+
+<sect2>
+<title>Notification CONFIG</title>
+
+<para>
+ Ces lignes sont assez triviales. Ce sont des messages d'information à propos
+ de la configuration.
+</para>
+
+<para>
+ Voici quelques lignes typiques que vous pouvez rencontrer :
+ <screen>CONFIG main: local node id = 1
+CONFIG main: loading current cluster configuration
+CONFIG storeNode: no_id=3 no_comment='Node 3'
+CONFIG storePath: pa_server=5 pa_client=1 pa_conninfo="host=127.0.0.1 dbname=foo user=postgres port=6132" pa_connretry=10
+CONFIG storeListen: li_origin=3 li_receiver=1 li_provider=3
+CONFIG storeSet: set_id=1 set_origin=1 set_comment='Set 1'
+CONFIG main: configuration complete - starting threads</screen>
+</para>
+
+</sect2>
+
+<sect2>
+<title>Notifications DEBUG</title>
+
+<para>
+ Les notifications DEBUG sont moins intéressantes et ne vous seront utiles
+ que lorsque vous rencontrez une problème avec &slony1;.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Nom du processus </title>
+
+<para>
+ Les notifications sont toujours précédées par le nom du processus qui produit
+ cette notification. Vous verrez des messages en provenance des processus
+ suivants :
+
+ <variablelist>
+ <varlistentry>
+ <term>localListenThread</term>
+ <listitem>
+ <para>
+ Le processus local qui écoute les événements sur le nœud local.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>remoteWorkerThread-X</term>
+ <listitem>
+ <para>
+ Les processus qui traitent les événements distants. Vous verrez un de
+ ces processus pour chaque nœud qui est en communication avec le
+ nœud local.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>remoteListenThread-X</term>
+ <listitem>
+ <para>
+ Les processus qui écoutent les événements distants. Vous verrez un
+ de ces processus pour chaque nœud du cluster.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>cleanupThread</term>
+ <listitem>
+ <para>
+ Le processus qui prend en charge les opérations telles que les
+ VACUUM, le nettoyage des tables confirm et event et la suppression
+ des données périmées.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>syncThread</term>
+ <listitem>
+ <para>
+ Le processus qui produit les événements SYNC.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+</para>
+
+<para>
+ La quantité d'information que ces processus affichent est contrôlée par le
+ paramètre <envar>log_level</envar> de &lslon;. Les messages de type
+ ERROR/WARN/CONFIG/INFO seront toujours affichés. Augmenter la valeur de 1 à
+ 4 affichera des plus en plus de messages de niveau DEBUG.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Comment lire les traces de &slony1;</title>
+<indexterm><primary>lire et comprendre les traces de &slony1;</primary></indexterm>
+
+<para>
+ Notons que, du point de vue d'un processus slon, il n'y a pas de
+ <quote>maître</quote> ni d'<quote>esclave</quote>. Il y a juste des
+ nœuds.
+</para>
+
+<para>
+ On s'attend, de prime abord, à voir sur chaque nœuds des événements se
+ propager dans les deux sens. Dans un premier temps, il doit y avoir des
+ événements publiés qui témoignent de la création des nœuds et des
+ voies de communications. Si vous ne les voyez pas, alors les nœuds
+ ne communiquent pas correctement entre eux et rien ne va se passer...
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>Créer les deux nœuds.</para>
+
+ <para>
+ Aucun slon ne fonctionne à ce stade, donc il n'y a aucune trace à
+ consulter.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Lancer les deux nœuds</para>
+
+ <para>
+ Les traces de chaque nœud n'auront pas une activité débordante
+ car aucun des nœuds n'a pas grand chose à dire et qu'ils ne savent
+ pas comment communiquer entre eux. Chaque nœud génère périodiquement
+ un événement <command>SYNC</command>, mais ne perçoit
+ <emphasis>rien</emphasis> de ce qui se passe sur les autres nœuds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Lancer <xref linkend="stmtstorepath"/> pour configurer les voies de
+ communications. Ceci devrait permettre aux nœuds de prendre
+ conscience de l'existence de leurs voisins.
+ </para>
+
+ <para>
+ Les traces de slon doivent maintenant indiquer la réception des événements
+ en provenance des nœuds <quote>étrangers</quote>.
+ </para>
+
+ <para>
+ Dans la 1.0, <xref linkend="table.sl-listen"/> n'est pas configuré
+ automatiquement, donc les traces vont rester calmes tant que vous n'aurez
+ pas soumis explicitement les requêtes <command>STORE LISTEN</command>.
+ Dans la version 1.1, les <quote>voies d'écoute</quote> sont configurées
+ automatiquement, ce qui nous donne un réseau de communication
+ opérationnel plus rapidement.
+ </para>
+
+ <para>
+ Si vous consultez le contenu des tables <xref linkend="table.sl-node"/>,
+ <xref linkend="table.sl-path"/> et <xref linkend="table.sl-listen"/> sur
+ chaque nœud, cela vous donnera une bonne idée de l'état du réseau
+ de communication. Jusqu'à ce que les <xref linkend="slon"/> démarrent,
+ chaque nœud est partiellement configuré. Si le cluster contient
+ deux nœuds, alors il doit y avoir deux entrées dans chacune des
+ trois tables une fois que les communications sont correctement
+ configurées. S'il y a moins d'entrées, vous devriez pouvoir deviner ce
+ qui manque.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si nécessaire (<emphasis>c'est-à-dire</emphasis> - si votre version est
+ antérieure à la version 1.1), lancez des requêtes <xref
+ linkend="stmtstorelisten"/> pour indiquer comment les nœuds
+ utiliseront les voies de communications.
+ </para>
+
+ <para>
+ Une fois que c'est fait, les traces des nœuds afficheront un niveau
+ d'activité supérieur, notamment les événements produits périodiquement
+ sur les différents nœuds, ainsi que leur propagation.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Configurez l'ensemble de réplication avec (<xref
+ linkend="stmtcreateset"/>), ajoutez les tables avec (<xref
+ linkend="stmtsetaddtable"/>), les séquences avec (<xref
+ linkend="stmtsetaddsequence"/>), puis vérifiez que vous retrouvez des
+ traces adéquates avec <xref linkend="logaddobjects"/> uniquement dans
+ les traces du nœud d'origine de l'ensemble de réplication.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Soumettre une requête <xref linkend="stmtsubscribeset"/>, l'événement
+ devrait être visible sur les deux nœuds.
+ </para>
+
+ <para>
+ Il reste quelques actions à mener sur le nœud origine... L'abonné
+ doit ensuite recevoir un événement <command>COPY_SET</command>, ce qui
+ doit afficher des informations dans les traces à propos de l'ajout de
+ chaque table et de la copie de leurs données. Consultez la section
+ <xref linkend="logsubtime"/> pour plus de détails.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ À partir de là, vous constaterez deux types de comportements :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Sur le nœud origine, peu d'informations seront enregistrés dans
+ les traces, juste des indications sur les événements <command>SYNC</command>
+ générés et confirmés par les autres nœuds. Consultez la section
+ <xref linkend="lognormalsync"/> pour plus d'informations sur les
+ différents types de traces que vous pouvez rencontrer.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Sur le nœud abonné, vous trouverez des rapports sur les événements
+ <command>SYNC</command> et sur les données que l'abonné obtient du
+ fournisseur. Ceci se produit peu fréquemment si le nœud origine ne
+ reçoit pas de mises à jour ; c'est au contraire très fréquent si le
+ nœud origine reçoit beaucoup de modifications.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2>
+<title>Les traces et leurs implications</title>
+
+<para>
+ Cette section énumère les nombreux messages d'erreurs que l'on peut trouver
+ dans les traces de &slony1;, ainsi qu'une brève explication de leur
+ implication. Il s'agit d'une liste relativement compréhensible, qui omet
+ simplement certains messages de niveau <command>DEBUG4</command> qui sont
+ presque toujours inintéressants.
+</para>
+
+<sect3 id="logshiplog">
+<title>Traces associées au Log Shipping</title>
+
+<para>
+ La plupart de ces messages concernent des erreurs qui se produisent lorsque
+ le mécanisme de <xref linkend="logshipping"/> échoue. En général, cela se
+ produit si le système de fichiers utilisé pour le log shipping est plein ou
+ si les droits d'un répertoire sont mal définies.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: log archive failed %s - %s\n</command>
+ </para>
+
+ <para>
+ Ce message indique qu'une erreur a été rencontrée en essayent d'écrire
+ un fichier de log shipping. Normalement, le démon &lslon; essaie à
+ nouveau jusqu'à ce qu'il réussisse.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: writing archive log...</command>
+ </para>
+
+ <para>
+ Ce message indique qu'un fichier d'archive est écrit pour un ensemble de
+ <command>SYNC</command> particulier.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>INFO: remoteWorkerThread_%d: Run Archive Command %s</command>
+ </para>
+
+ <para>
+ Si &lslon; est configuré (avec l'option <option>-x</option>, c'est-à-dire
+ <envar>command_on_logarchive</envar>) pour lancer une commande après
+ chaque génération de fichier d'archive, ce message indique quand cette
+ commande est effectuée via la fonction <function>system()</function>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: Could not open COPY SET archive file %s - %s</command>
+ </para>
+
+ <para>
+ Ce message semble assez explicite...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: Could not generate COPY SET archive header %s - %s</command>
+ </para>
+
+ <para>
+ Ce message signifie probablement que vous avez saturé le système de fichier...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR remoteWorkerThread_%d: "update "_slony_regress1".sl_archive_counter set ac_num = ac_num + 1, ac_timestamp = CURRENT_TIMESTAMP; select ac_num, ac_timestamp from "_slony_regress1".sl_archive_counter; " PGRES_FATAL_ERROR ERROR: could not serialize access due to concurrent update</command>
+ </para>
+
+ <para>
+ Ce message se produit occasionnellement lorsqu'on utilise le log
+ shipping ; il se produit généralement lorsque que le cluster
+ contient trois nœuds ou plus, et que le démon tente d'exécuter
+ simultanément des événements en provenance de différents nœuds.
+ Ceci ne représente pas un problème sérieux ; &slony1; tentera à
+ nouveau de traiter l'événement qui a échoué, sans que l'intervention
+ d'un administrateur ne soit nécessaire.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect3>
+
+<sect3 id="ddllogs">
+<title>Traces à propose des scripts DDL</title>
+
+<para>
+ La gestion des ordres DDL est un peu fragile, comme indiqué dans la section
+ <xref linkend="ddlchanges"/> ; voici des messages à caractère informatif
+ et des messages d'erreur qui se produisent lors de l'exécution d'une requête
+ <xref linkend="stmtddlscript"/>.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: DDL préparation failed - set %d - only on node %</command>
+ </para>
+
+ <para>
+ Quelque chose s'est cassé lors du traitement d'un script DDL sur un des
+ nœuds. Ceci indique probablement que le schéma du nœud était
+ différent de celui du nœud origine ; vous devez probablement
+ effectuer une modification à la main sur ce nœud pour que
+ l'événement puisse être traité. Une alternative très regrettable consiste
+ à supprimer l'événement bloquant, sachant qu'il est possible que cette
+ suppression ne fonctionne pas...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>SLON_CONFIG: remoteWorkerThread_%d: DDL request with %d statements</command>
+ </para>
+
+ <para>
+ Ce message est informatif, il indique combien de commandes SQL ont été traitées.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>SLON_ERROR: remoteWorkerThread_%d: DDL had invalid number of statements - %d</command>
+ </para>
+
+ <para>
+ Ce message se produit lorsque le nombre de commandes traitées est
+ inférieure à 0 (ce qui est théoriquement impossible) ou supérieure à
+ MAXSTATEMENTS. Ceci indique que le script DDL est probablement mal
+ écrit...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: malloc() failure in DDL_SCRIPT - could not allocate %d bytes of memory</command>
+ </para>
+
+ <para>
+ Ceci se produit uniquement si vous soumettez un script DDL
+ extraordinairement long, qui sature la mémoire allouée à &lslon;
+ (« out of memory »).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>CONFIG: remoteWorkerThread_%d: DDL Statement %d: [%s]</command>
+ </para>
+
+ <para>
+ Ce message fait la liste de tous les ordres DDL au fur et à mesure qu'ils
+ sont soumis.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: DDL Statement failed - %s</command>
+ </para>
+
+ <para>
+ Un des ordres DDL a fonctionné sur le nœud origine mais il a
+ échoué sur le nœud local...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>CONFIG: DDL Statement success - %s</command>
+ </para>
+
+ <para>
+ Tout va bien...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: Could not generate DDL archive tracker %s - %s</command>
+ </para>
+
+ <para>
+ Apparemment, le script DDL ne peut pas être écrit dans le fichier de log
+ shipping...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: Could not submit DDL script %s - %s</command>
+ </para>
+
+ <para>
+ Le script ne peut pas être écrit dans un fichier de log shipping.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: Could not close DDL script %s - %s</command>
+ </para>
+
+ <para>
+ Impossible de fermer un fichier de log shipping contenant un script DDL.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I ddlScript_prepare(): set % not found</command>
+ </para>
+
+ <para>
+ L'ensemble de réplication est introuvable sur ce nœud; Vous avez
+ probablement spécifié un mauvais identifiant de nœud...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I ddlScript_prepare_int(): set % not found</command>
+ </para>
+
+ <para>
+ L'ensemble de réplication est introuvable sur ce nœud. Vous avez
+ probablement spécifié un mauvais identifiant de nœud...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: alterTableForReplication(): Table with id % not found</command>
+ </para>
+
+ <para>
+ Apparemment, la table n'a pas été trouvée. Le schéma est peut-être erroné ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: alterTableForReplication(): Table % is already in altered state</command>
+ </para>
+
+ <para>
+ Curieux... Le script tente de répliquer une table une
+ <emphasis>seconde</emphasis> fois ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: alterTableRestore(): Table with id % not found</command>
+ </para>
+
+ <para>
+ Ce message se produit lorsqu'une table est en cours de restauration vers
+ un état <quote>non-repliqué</quote> ; apparemment, la table
+ répliquée n'a pas été trouvée.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: alterTableRestore(): Table % is not in altered state</command>
+ </para>
+
+ <para>
+ La table n'est pas dans un état répliqué. Cela ne devrait pas se produire
+ si la réplication fonctionne correctement...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>NOTICE: Slony-I: alterTableForReplication(): multiple instances of trigger % on table %'',</command>
+ </para>
+
+ <para>
+ Ceci se produit en général lorsque vous avez une table avec des triggers
+ que la réplication a dû cacher lors de l'abonnement du nœud et que
+ vous avez ajouté un triggrer portant le même nom. Maintenant, lorsque l'on
+ tente de réactiver le trigger caché, les deux triggers entrent en conflit.
+ </para>
+
+ <para>
+ Le script DDL continuera a tourner, encore et encore, ou la commande
+ UNINSTALL NODE échouera, jusqu'à ce que vous supprimiez le trigger
+ <quote>visible</quote> à la main puisque vous l'avez probablement ajouté
+ à la main un peu plus tôt.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: Unable to disable triggers</command>
+ </para>
+
+ <para>
+ Cette erreur se produit à la suite du problème de <quote>triggers
+ multiples</quote>.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect3>
+
+<sect3>
+<title>Problèmes avec les processus</title>
+
+<para>
+ Le modèle de gestion des processus ("threading") de &slony1; n'est pas
+ directement <quote>paramétrable par les utilisateurs</quote>. Chaque démon
+ &lslon; crée un ensemble pré-défini de processus pour gérer les différentes
+ connexions nécessaires. La seule occasion où la gestion des processus peut
+ poser problème est lorsque les bibliothèques de &postgres; n'ont pas été
+ compilées <quote>correctement</quote>, auquel cas il sera de toute façon
+ impossible de compiler &slony1;.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <command>FATAL: remoteWorkerThread_%d: pthread_create() - %s</command>
+ </para>
+
+ <para>
+ Impossible de créer un nouveau processus de traitement des événements distants.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1 remoteWorkerThread_%d: helper thread for provider %d created</command>
+ </para>
+
+ <para>
+ Ceci se produit en général lorsque le démon &lslon; démarre : un
+ processus est créé pour chaque nœud que le nœud local doit
+ écouter.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1: remoteWorkerThread_%d: helper thread for provider %d terminated </command>
+ </para>
+
+ <para>
+ Si un abonnement est modifié et qu'un nœud n'est plus un nœud
+ fournisseur, alors le processus qui traite les événements sur ce
+ nœud peut être arrêté.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1: remoteWorkerThread_%d: disconnecting from data provider %d</command>
+ </para>
+
+ <para>
+ Un nœud fournisseur qui n'est plus utilisé peut être supprimé ;
+ si les informations de connexion sont changées, le démon &lslon; doit se
+ déconnecter et se reconnecter.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: ignore new events due to shutdown</command>
+ </para>
+
+ <para>
+ Si le démon &lslon; est en cours d'arrêt, il est futile de traiter d'autres événements.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1: remoteWorkerThread_%d: node %d - no worker thread</command>
+ </para>
+
+ <para>
+ Curieux : il est impossible de réveiller le processus de
+ traitement ; pourtant il devrait déjà y en avoir un...
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect3>
+
+<sect3 id="logsubtime">
+<title>Traces au moment d'un abonnement</title>
+
+<para>
+ Un abonnement est une opération très spéciale pour &slony1;. Si vous avez un
+ grand volume de données à copier sur l'abonné, cela peut prendre un temps
+ considérable. &slony1; enregistre une quantité considérable d'informations
+ lors de ce processus, qui sera probablement très utile aux utilisateurs. En
+ particulier, il produit des traces à chaque fois qu'il commence et termine
+ la copie des données d'une table et lorsqu'il finit l'indexation de la table.
+ Cela ne rend pas un abonnement de 28 heures plus rapide, mais au moins cela
+ vous aide à suivre son déroulement.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <command>DEBUG1: copy_set %d</command>
+ </para>
+
+ <para>
+ Ceci indique le départ de la copie de données pour un nouvel abonnement.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: set %d not found in runtime configuration </command>
+ </para>
+
+ <para>
+ &lslon; a tenté de lancer un abonnement ; il n'a pas trouvé les
+ informations de connexion à la source des données. Peut-être que les
+ chemins ne sont pas correctement propagés ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: node %d has no pa_conninfo</command>
+ </para>
+
+ <para>
+ Apparemment, les informations de connexion sont
+ <emphasis>fausses</emphasis>...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: copy set %d cannot connect to provider DB node %d</command>
+ </para>
+
+ <para>
+ &lslon; n'a pas pu se connecter au fournisseur. Est-ce que les
+ informations de connexion sont fausses ? Peut-être que
+ l'authentification est mal configurée ? Peut-être que la base de
+ donnée ne fonctionne pas ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1: remoteWorkerThread_%d: connected to provider DB</command>
+ </para>
+
+ <para>
+ Excellent : le processus de copie a pu se connecter au fournisseur.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: sequenceSetValue(): sequence % not found</command>
+ </para>
+
+ <para>
+ Curieux ; la séquence de l'objet est absente. Est-ce que quelqu'un
+ l'a supprimé à la main du schéma ? (<emphasis>c'est-à-dire</emphasis>
+ sans utiliser <xref linkend="stmtddlscript"/>)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: subscribeSet() must be called on provider</command>
+ </para>
+
+ <para>
+ Cette fonction devrait être appelée sur le nœud fournisseur.
+ Normalement, &lslonik; gère correctement ce cas, à moins qu'il y ait de
+ mauvais DSN dans un script &lslonik;...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: subscribeSet(): set % not found</command>
+ </para>
+
+ <para>
+ Le nœud fournisseur ne connaît pas cet ensemble de réplication.
+ Un mauvais paramètre dans un script &lslonik; ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: subscribeSet(): set origin and receiver cannot be identical</command>
+ </para>
+
+ <para>
+ Un nœud origine ne peut pas être abonné à lui-même.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: subscribeSet(): set provider and receiver cannot be identical</command>
+ </para>
+
+ <para>
+ Un nœud récepteur doit s'abonner à un nœud
+ <emphasis>différent</emphasis>...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>Slony-I: subscribeSet(): provider % is not an active forwarding node for replication set %</command>
+ </para>
+
+ <para>
+ Vous devez utiliser un nœud fournisseur actif et en cours de
+ fonctionnement comme source des données.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>Slony-I: subscribeSet_int(): set % is not active, cannot change provider</command>
+ </para>
+
+ <para>
+ Vous ne pouvez pas changer le fournisseur pour le moment...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>Slony-I: subscribeSet_int(): set % not found</command>
+ </para>
+
+ <para>
+ Ce nœud ne connaît pas l'ensemble de réplication... Vous avez
+ peut-être soumis un mauvais paramètre ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>Slony-I: unsubscribeSet() must be called on receiver</command>
+ </para>
+
+ <para>
+ Cela parait trivial... Ceci indique probablement un mauvais DSN &lslonik;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>Slony-I: Cannot unsubscribe set % while being provider</command>
+ </para>
+
+ <para>
+ Cela semble évident ; <xref linkend="stmtunsubscribeset"/> va
+ échouer si un nœud est dépendant des abonnés dont il est le
+ fournisseur.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>Slony-I: cleanupEvent(): Single node - deleting events < %</command>
+ </para>
+
+ <para>
+ S'il n'y a qu'un seul nœud, l'événement de nettoyage va supprimer
+ les anciens événements afin de ne pas récupérer le <quote>crud</quote>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>Slony-I: tableAddKey(): table % not found</command>
+ </para>
+
+ <para>
+ Peut-être que vous n'avez pas copié le schéma proprement ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>Slony-I: tableDropKey(): table with ID% not found</command>
+ </para>
+
+ <para>
+ Cela paraît curieux ; cette table est probablement déjà en cours de
+ réplication ; il est donc étrange que cette table ait disparue.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>Slony-I: determineIdxnameUnique(): table % not found</command>
+ </para>
+
+ <para>
+ Avez-vous correctement copié le schéma sur le nouveau nœud ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>Slony-I: table % has no primary key</command>
+ </para>
+
+ <para>
+ Ceci signifie probablement que le chargement du schéma s'est mal passé...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>Slony-I: table % has no unique index %</command>
+ </para>
+
+ <para>
+ Ceci signifie probablement que le chargement du schéma s'est mal passé...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>WARN: remoteWorkerThread_%d: transactions earlier than XID %s are still in progress</command>
+ </para>
+
+ <para>
+ Ceci indique qu'une vieille transaction est en cours d'exécution et
+ qu'elle a débutée avant le plus vieil événement <command>SYNC</command>
+ disponible sur le fournisseur. &slony1; ne peut pas lancer une réplication
+ tant que cette transaction n'est pas achevée. Ce message sera répété
+ jusqu'à ce que la transaction aboutisse...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: prepare to copy table %s</command>
+ </para>
+
+ <para>
+ Ceci indique que &lslon; commence les préparatifs pour mettre en place un
+ abonnement pour une table.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1: remoteWorkerThread_%d: table %s will require Slony-I serial key</command>
+ </para>
+
+ <para>
+ Évidemment, cette table est définie avec <xref linkend="stmttableaddkey"/>
+ et &slony1; a ajouté une clef primaire supplémentaire.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: Could not lock table %s on subscriber</command>
+ </para>
+
+ <para>
+ Pour une certaine raison, la table ne peut pas être verrouillée, donc la
+ réplication doit être redémarrée. Si le problème concerne un inter-blocage
+ (« deadlock »), essayer la commande à nouveau peut fonctionner.
+ S'il s'agit d'un autre problème, vous devez intervenir...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: all tables for set %d found on subscriber</command>
+ </para>
+
+ <para>
+ Ce message d'information indique que lors du premier passage sur les tables,
+ aucun problème n'a été trouvé...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: copy sequence %s</command>
+ </para>
+
+ <para>
+ Ce message indique qu'une séquence est traitée...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: copy table %s</command>
+ </para>
+
+ <para>
+ &lslon; commence la copie d'une table...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG3: remoteWorkerThread_%d: table %s Slony-I serial key added local</command>
+ </para>
+
+ <para>
+ Une nouvelle colonne vient d'être ajoutée dans la table afin qu'elle
+ dispose d'une clef primaire.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG3: remoteWorkerThread_%d: local table %s already has Slony-I serial key</command>
+ </para>
+
+ <para>
+ Il n'est pas nécessaire d'ajouter une clef de type 'serial' ;
+ apparemment, elle existe déjà.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG3: remoteWorkerThread_%d: table %s does not require Slony-I serial key</command>
+ </para>
+
+ <para>
+ Apparemment, cette table n'a pas besoin d'une clef primaire supplémentaire...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG3: remoteWorkerThread_%d: table %s Slony-I serial key added local</command>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: Begin COPY of table %s</command>
+ </para>
+
+ <para>
+ &lslon; va lancer la commande COPY des deux côtés pour copier la table...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: Could not generate copy_set request for %s - %s</command>
+ </para>
+
+ <para>
+ Ceci indique que la requête <command>delete/copy</command> a échouée sur
+ l'abonné. Le &lslon; va répéter la tentative de
+ <command>COPY_SET</command> ; il est probable que l'opération continue
+ d'échouer...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: copy to stdout on provider - %s %s</command>
+ </para>
+
+ <para>
+ Évidemment, quelque chose ne fonctionne pas au niveau de l'opération
+ COPY vers la sortie <filename>stdout</filename> sur le nœud
+ fournisseur... l'événement va être lancé à nouveau...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: copy from stdin on local node - %s %s</command>
+ </para>
+
+ <para>
+ Évidemment, quelque chose n'a pas fonctionné lors de l'opération COPY
+ dans la table sur le nœud abonné... L'événement va être lancé à
+ nouveau...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: %d bytes copied for table %s</command>
+ </para>
+
+ <para>
+ Ce message indique que l'opération COPY sur la table est achevée. Ceci
+ est suivi d'un <command>ANALYZE</command> et d'une réindexation de la
+ table sur l'abonné.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: %.3f seconds to copy table %s</command>
+ </para>
+
+ <para>
+ Après ce message, la copie, la réindexation et l'analyse sont terminées sur l'abonné.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: set last_value of sequence %s (%s) to %s</command>
+ </para>
+
+ <para>
+ Sans surprise, cela indique qu'une séquence a été traitée sur l'abonnée.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: %.3 seconds to copy sequences</command>
+ </para>
+
+ <para>
+ Ce message indique le temps passé pour le traitement de l'événement
+ <command>COPY_SET</command>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: query %s did not return a result</command>
+ </para>
+
+ <para>
+ Ceci indique qu'une requête, exécutée lors du traitement final de
+ l'événement <command>COPY_SET</command>, a échoué. La copie est
+ redémarrée...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: copy_set no previous SYNC found, use enable event</command>
+ </para>
+
+ <para>
+ Ceci se produit si aucun événement SYNC n'a été trouvé ; l'événement
+ courant est positionné au niveau de l'événement
+ <command>ENABLE_SUBSCRIPTION</command>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: copy_set SYNC found, use event seqno %s</command>
+ </para>
+
+ <para>
+ Ceci se produit si un événement SYNC est trouvé ; l'événement
+ courant est positionné à la valeur indiquée.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: sl_setsync entry for set %d not found on provider</command>
+ </para>
+
+ <para>
+ Une information de synchronisation était attendue en provenance d'un
+ nœud abonné existant, mais elle n'a pas été trouvée. Il s'agit
+ probablement d'une erreur capable de bloquer la réplication...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1: remoteWorkerThread_%d: could not insert to sl_setsync_offline</command>
+ </para>
+
+ <para>
+ Après la configuration d'un abonné et presque tout est en place, des
+ écritures dans un fichier de log shipping ont échouées. Peut-être que
+ le disque est plein...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1: remoteWorkerThread_%d: %.3f seconds to build initial setsync status</command>
+ </para>
+
+ <para>
+ Ce message indique le temps total nécessaire pour que l'événement copy_set
+ soit réalisé...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1: remoteWorkerThread_%d: disconnected from provider DB</command>
+ </para>
+
+ <para>
+ À la fin d'un événement d'abonnement, le &lslon; de l'abonné va se
+ déconnecter du fournisseur et supprimer les connexions...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1: remoteWorkerThread_%d: copy_set %d done in %.3f seconds</command>
+ </para>
+
+ <para>
+ Ce message indique le temps total nécessaire pour effectuer la commande
+ copy_set... c'est le signe d'un abonné réussi !
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1: remoteWorkerThread_%d: copy_set %d done in %.3f seconds</command>
+ </para>
+
+ <para>
+ Ce message indique le temps total nécessaire pour effectuer la commande
+ copy_set... c'est le signe d'un abonné réussi !
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect3>
+
+<sect3 id="logmergeset">
+<title>Messages associés à la commande MERGE SET</title>
+
+<para>
+ Diverses exceptions peuvent conduire au rejet d'un <xref
+ linkend="stmtmergeset"/> ; ces problèmes doivent être réglés avant de
+ soumettre à nouveau la requête.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: merged set ids cannot be identical</command>
+ </para>
+
+ <para>
+ Il est illogique d'essayer de fusionner un ensemble avec lui-même.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: set % not found </command>
+ </para>
+
+ <para>
+ Un ensemble absent ne peut pas être fusionné.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: set % does not originate on local node</command>
+ </para>
+
+ <para>
+ La requête <xref linkend="stmtmergeset"/> doit être envoyée au nœud
+ origine des ensembles qu'il faut fusionner.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: subscriber lists of set % and % are different</command>
+ </para>
+
+ <para>
+ Les ensembles ne peuvent être fusionné que s'ils ont la même liste d'abonnés.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: set % has subscriptions in progress - cannot merge</command>
+ </para>
+
+ <para>
+ <xref linkend="stmtmergeset"/> ne peut pas fusionner tant que tous les
+ abonnements ne sont pas achevés. Si ce message apparaît, cela signifie
+ que les listes d'abonnées sont identiques mais qu'un ou plusieurs
+ nœuds n'ont pas terminé leur processus d'abonnement. Il est
+ probable qu'attendre une courte période avant de soumettre à nouveau la
+ requête <xref linkend="stmtmergeset"/> suffise à régler le problème.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect3>
+
+<sect3 id="lognormalsync">
+<title>Traces associés l'activité normale des SYNC</title>
+
+<para>
+ Certains de ces messages indiquent des erreurs mais,
+ <quote>normalement</quote>, ils présentent les informations attendues
+ lorsque la réplication fonctionne correctement.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: forward confirm %d,%s received by %d</command>
+ </para>
+
+ <para>
+ Ces événements devraient apparaître fréquemment et suivant une certaine
+ routine, car ils témoignent des confirmations d'événements qui sont
+ reçues.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1: remoteWorkerThread_%d: SYNC %d processing</command>
+ </para>
+
+ <para>
+ Ce message indique le début du traitement d'un <command>SYNC</command>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: No pa_conninfo for data provider %d</command>
+ </para>
+
+ <para>
+ Les informations de connexion au fournisseur ne sont pas disponibles.
+ Normalement, cela n'est pas possible...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteListenThread_%d: timeout for event selection</command>
+ </para>
+
+ <para>
+ Ce message signifie que le processus d'écoute
+ (<filename>src/slon/remote_listener.c</filename>) s'est arrêté après
+ avoir tenté de déterminer quels événements étaient en attente.
+ </para>
+
+ <para>
+ Ceci se produit lorsqu'une connexion réseau est coupée. Si c'est le cas,
+ redémarrer le démon &lslon; devrait suffire à résoudre le problème.
+ </para>
+
+ <para>
+ Par ailleurs, ceci peut se produire lorsque le démon &lslon; de ce
+ nœud a été en panne pendant longtemps, et qu'il y a une quantité
+ énorme de lignes dans la table <envar>sl_event</envar> sur ce nœud
+ ou sur d'autres, en attente d'être traitées et qu'il faut plus de <xref
+ linkend="slon-config-remote-listen-timeout"/> secondes pour exécuter la
+ requête SQL. Dans les anciennes version de &slony1;, ce paramètre de
+ configuration n'existait pas ; le temps maximum était fixé à 300
+ secondes. Dans les nouvelles versions, vous pouvez augmenter cette valeur
+ dans le fichier de configuration de &lslon; pour que le démon continue à
+ traiter les événements. Puis vous pourrez enquêter pour découvrir
+ pourquoi personne ne surveillait le processus et pourquoi la réplication
+ a été rompue pendant aussi longtemps...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: cannot connect to data provider %d on 'dsn'</command>
+ </para>
+
+ <para>
+ Nous n'avons pas les informations de connexions
+ <emphasis>correctes</emphasis> pour nous connecter au fournisseur de
+ données.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1: remoteWorkerThread_%d: connected to data provider %d on 'dsn'</command>
+ </para>
+
+ <para>
+ Excellent ; le démon &lslon; s'est connecté au fournisseur.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>WARN: remoteWorkerThread_%d: don't know what ev_seqno node %d confirmed for ev_origin %d</command>
+ </para>
+
+ <para>
+ Il n'y a aucune information de confirmation en provenance de ce
+ fournisseur ; il faut annuler le <command>SYNC</command> et attendre
+ en espérant que cette information arrive rapidement...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1: remoteWorkerThread_%d: data provider %d only confirmed up to ev_seqno %d for ev_origin %d </command>
+ </para>
+
+ <para>
+ Le fournisseur de ce nœud est un abonné. Apparemment, cet abonné
+ est en retard. Le démon &lslon; doit attendre que le fournisseur rattrape
+ son retard avant de recevoir de <emphasis> nouvelles</emphasis> données.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: data provider %d confirmed up to ev_seqno %s for ev_origin %d - OK</command>
+ </para>
+
+ <para>
+ Très bien ; le fournisseur dispose des données dont l'abonné a besoin...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: syncing set %d with %d table(s) from provider %d</command>
+ </para>
+
+ <para>
+ Ce message indique les plans d'actions d'un <command>SYNC</command> :
+ il y a un ensemble de tables à traiter.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: ssy_action_list value: %s length: %d</command>
+ </para>
+
+ <para>
+ Cette partie de la requête a collecté des données qui semblent être
+ <quote>volumineuses</quote> ; ce message indique comment elles ont
+ été compressées...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: Didn't add OR to provider</command>
+ </para>
+
+ <para>
+ Ce message indique qu'il n'y avait rien dans une clause
+ <quote>fournisseur</quote> à l'intérieur de la requête qui collecte les
+ données à appliquer, ce qui ne devrait pas se produire. Il est probable
+ que les choses aient mal tournées quelque part...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: no sets need syncing for this event</command>
+ </para>
+
+ <para>
+ Ceci se produira pour tous les événements <command>SYNC</command> générés
+ sur les nœuds qui ne sont pas l'origine d'un ensemble de
+ réplication. Vous pouvez vous attendre à voir ces messages assez
+ fréquemment.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG3: remoteWorkerThread_%d: activate helper %d</command>
+ </para>
+
+ <para>
+ Un processus va être lancé pour aider à traiter les données de l'événement
+ <command>SYNC</command>...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG4: remoteWorkerThread_%d: waiting for log data</command>
+ </para>
+
+ <para>
+ Le processus attend que les données se consument (c'est-à-dire qu'elles
+ soient appliquées sur le réplicat).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: %s %s - qualification was %s</command>
+ </para>
+
+ <para>
+ Apparemment, l'application de données répliquées sur l'abonné a échoué....
+ ceci indique très certainement une corruption assez grave.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: replication query did not affect one row (cmdTuples = %s) - query was: %s qualification was: %s</command>
+ </para>
+
+ <para>
+ Si <envar>SLON_CHECK_CMDTUPLES</envar> est défini, &lslon; applique les
+ changements ligne par ligne, et vérifie que chaque changement affecte
+ exactement une ligne. Apparemment, ce n'était pas le cas ici, ce qui
+ semble indiquer une corruption de la réplication. C'est plutôt une
+ mauvaise nouvelle...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: SYNC aborted</command>
+ </para>
+
+ <para>
+ Le <command>SYNC</command> a été annulé. Le &lslon; va probablement
+ tenter de nouveau ce <command>SYNC</command> dans quelque temps. Si le
+ <command>SYNC</command> échoue encore et toujours, il y un problème
+ récurrent et la réplication ne va probablement pas reprendre sans une
+ intervention. Il est peut-être nécessaire de désabonner/réabonner
+ l'ensemble de réplication concerné, ou si il n'y a qu'un seul ensemble
+ de réplication sur le nœud esclave, il est parfois plus simple de
+ supprimer et de recréer le nœud. Si les connexions de l'application
+ peuvent être détournées vers le nœud maître pendant cette opération,
+ alors il n'est pas nécessaire d'arrêter le service.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: new sl_rowid_seq value: %s</command>
+ </para>
+
+ <para>
+ Ce message rend compte de la progression de cette séquence interne de
+ &slony1;.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: SYNC %d done in %.3f seconds</command>
+ </para>
+
+ <para>
+ Ce message indique qu'un <command>SYNC</command> s'est achevé correctement.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG1: remoteWorkerThread_%d_d:%.3f seconds delay for first row </command>
+ </para>
+
+ <para>
+ Ce message indique combien de temps il a fallu pour récupérer la première
+ ligne du curseur LOG qui lit les données dans les tables sl_log tables.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d_d: large log_cmddata for actionseq %s not found</command>
+ </para>
+
+ <para>
+ &lslon; n'a pas trouvé les données relatives à une <quote>très
+ grande</quote> ligne de la table sl_log qui a été récupéré
+ individuellement. Ceci ne devrait pas se produire.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d_d:%.3f seconds until close cursor</command>
+ </para>
+
+ <para>
+ Ceci indique combien de temps il a fallu pour lire les données dans le
+ curseur LOG qui extrait les données des tables sl_log.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d_d: inserts=%d updates=%d deletes=%d</command>
+ </para>
+
+ <para>
+ Ce message montre l'activité enregistrée dans le <command>SYNC</command>
+ courant.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG3: remoteWorkerThread_%d: compress_actionseq(list,subquery) Action list: %s</command>
+ </para>
+
+ <para>
+ Ce message indique qu'une partie de la requête du curseur LOG va être
+ compressée. (Dans certains cas, les requêtes peuvent grossir jusqu'à
+ une taille <emphasis>énorme</emphasis> et faire exploser l'analyseur
+ de requêtes...).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG3: remoteWorkerThread_%d: compressed actionseq subquery %s</command>
+ </para>
+
+ <para>
+ Ce message indique comment la sous-requête a été compressée.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect3>
+
+<sect3 id="logaddobjects">
+<title>Traces concernant l'ajout d'objets dans des ensembles de réplication</title>
+
+<para>
+ Ces messages apparaîtront dans les traces d'un nœud origine au moment
+ où vous configurerez un ensemble de réplication ; certains apparaîtront
+ sur les nœuds abonnés lors de leur abonnement.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: setAddTable_int(): table % has no index %</command>
+ </para>
+
+ <para>
+ Apparemment, l'index de clé étrangère spécifié est absent sur ce
+ nœud...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setAddTable_int(): table % not found</command>
+ </para>
+
+ <para>
+ La table n'a pas été trouvé sur ce nœud ; avez-vous chargé
+ correctement le schéma ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setAddTable_int(): table % is not a regular table</command>
+ </para>
+
+ <para>
+ Vous avez tenté de répliquer quelque chose qui n'est pas dans la
+ table ; vous ne pouvez pas faire ça !
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>NOTICE: Slony-I setAddTable_int(): table % PK column % nullable</command>
+ </para>
+
+ <para>
+ Vous avez tenté de répliquer une table dont une colonne de la clef
+ primaire candidate peut être NULL. Toutes les colonnes participant à
+ une clef primaire doivent être <command>NOT NULL</command>. Cette
+ requête va échouer.
+ </para>
+
+ <para>
+ Une vérification de cette condition fut introduit dans la version 1.2 de
+ &slony1;. Si vous avez un réplicat 1.1, il va continuer à fonctionner
+ après la mise à jour en 1.2 mais vous rencontrerez ce message lorsque
+ vous essaierez d'ajouter de nouveaux abonnés.
+ </para>
+
+ <para>
+ Vous pouvez chercher des combinaisons table/index ayant des colonnes
+ pouvant être NULL sur un nœud existant avec la requête
+ suivante :
+ <screen>select c.relname as table_name, ic.relname as index_name, att.attname, att2.attnotnull
+from _cluster.sl_table t, pg_catalog.pg_class c, pg_index i, pg_catalog.pg_class ic, pg_catalog.pg_attribute att, pg_catalog.pg_attribute att2
+where t.tab_reloid = c.oid
+and t.tab_idxname = ic.relname
+and ic.oid = i.indexrelid
+and att.attrelid = i.indexrelid
+and att2.attname = att.attname
+and att2.attrelid = c.oid
+and att2.attnotnull = 'f';</screen>
+ </para>
+
+ <para>
+ Ces cas peuvent être rectifiés en exécutant à chaque fois une requête du
+ type :
+ <command>alter table matable alter column nullablecol set not null;</command>
+ Lancée sur un abonné ayant une table vide, cette requête s'exécutera très
+ rapidement. Elle prendra plus de temps sur une table qui contient déjà
+ beaucoup de données car la modification nécessite un parcours de la table
+ pour vérifier qu'il n'existe aucune ligne ayant la valeur NULL dans la
+ colonne.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setAddTable_int(): table % not replicable!</command>
+ </para>
+
+ <para>
+ Ceci se produit à cause d'une colonne qui n'est pas NOT NULL dans une
+ clef primaire.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setAddTable_int(): table id % has already been assigned!</command>
+ </para>
+
+ <para>
+ L'identifiant de la table doit être assigné de manière unique dans <xref
+ linkend="stmtsetaddtable"/> ; apparemment, vous avez demandé une
+ valeur qui est déjà utilisée.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setAddSequence(): set % not found</command>
+ </para>
+
+ <para>
+ Apparemment, l'ensemble que vous demandez n'est pas disponible...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setAddSequence(): set % has remote origin</command>
+ </para>
+
+ <para>
+ Vous pouvez uniquement ajouter des objets sur le nœud origine.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setAddSequence(): cannot add sequence to currently subscribed set %</command>
+ </para>
+
+ <para>
+ Apparemment, l'ensemble de réplication que vous demandez a déjà été
+ abonné. Vous ne pouvez pas ajouter des tables/séquences dans un ensemble
+ qui a déjà des abonnés. Vous devez créer un nouvel ensemble, y ajouter
+ des objets et définir ses abonnements
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setAddSequence_int(): set % not found</command>
+ </para>
+
+ <para>
+ Apparemment, l'ensemble que vous demandez n'est pas disponible...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setAddSequence_int(): sequence % not found</command>
+ </para>
+
+ <para>
+ Apparemment, la séquence que vous demandez n'est pas disponible sur ce
+ nœud. Comment avez-vous mis en place le schéma sur les nœuds
+ abonnés ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setAddSequence_int(): % is not a sequence</command>
+ </para>
+
+ <para>
+ Ce message est assez évident.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setAddSequence_int(): sequence ID % has already been assigned</command>
+ </para>
+
+ <para>
+ Chaque identifiant de séquence ajouté doit être unique. Apparemment, vous
+ avez réutilisé un identifiant déjà existant.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect3>
+
+<sect3>
+<title>Traces lors du déplacement d'un objet d'un ensemble vers un autre</title>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setMoveTable_int(): table % not found</command>
+ </para>
+
+ <para>
+ La table n'a pas été trouvée sur ce nœud ; vous avez
+ probablement indiqué le mauvais identifiant.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setMoveTable_int(): set ids cannot be identical</command>
+ </para>
+
+ <para>
+ Quel est l'intérêt de déplacer une table dans un ensemble où elle se
+ trouve déjà ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setMoveTable_int(): set % not found</command>
+ </para>
+
+ <para>
+ L'ensemble n'a pas été trouvé sur le nœud ; vous avez
+ probablement indiqué un mauvais identifiant.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setMoveTable_int(): set % does not originate on local node</command>
+ </para>
+
+ <para>
+ L'ensemble n'est pas originaire de ce nœud ; vous avez
+ probablement indiqué le mauvais EVENT NODE.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setMoveTable_int(): subscriber lists of set % and % are different</command>
+ </para>
+
+ <para>
+ Vous pouvez uniquement déplacer les objets entre des ensembles qui ont
+ la même liste d'abonnés.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setMoveSequence_int(): sequence % not found</command>
+ </para>
+
+ <para>
+ La séquence n'a pas été trouvée sur ce nœud ; vous avez
+ probablement indiqué un mauvais identifiant.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setMoveSequence_int(): set ids cannot be identical</command>
+ </para>
+
+ <para>
+ Quel est l'intérêt de déplacer une séquence dans un ensemble où elle se
+ trouve déjà ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setMoveSequence_int(): set % not found</command>
+ </para>
+
+ <para>
+ L'ensemble n'a pas été trouvé sur le nœud ; vous avez
+ probablement indiqué un mauvais identifiant.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setMoveSequence_int(): set % does not originate on local node</command>
+ </para>
+
+ <para>
+ L'ensemble n'est pas originaire de ce nœud ; vous avez
+ probablement indiqué le mauvais EVENT NODE.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setMoveSequence_int(): subscriber lists of set % and % are different</command>
+ </para>
+
+ <para>
+ Vous pouvez uniquement déplacer les objets entre des ensembles qui ont la
+ même liste d'abonnés.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect3>
+
+<sect3>
+<title>Problèmes lors de la suppression d'objets</title>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setDropTable(): table % not found</command>
+ </para>
+
+ <para>
+ La table n'a pas été trouvée sur ce nœud. Êtes-vous sûr d'avoir
+ indiqué le bon identifiant ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setDropTable(): set % not found</command>
+ </para>
+
+ <para>
+ L'ensemble de réplication n'a pas été trouvé sur ce nœud.
+ Êtes-vous sûre d'avoir indiqué le bon identifiant ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setDropTable(): set % has remote origin</command>
+ </para>
+
+ <para>
+ L'ensemble de réplication n'a pas ce nœud pour origine. Vous
+ devez probablement spécifier le paramètre <command>EVENT NODE</command>
+ dans la commande <xref linkend="stmtsetdroptable"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setDropSequence_int(): sequence % not found</command>
+ </para>
+
+ <para>
+ Est-ce que cette séquence ne se trouverait pas plutôt dans un autre
+ ensemble ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setDropSequence_int(): set % not found</command>
+ </para>
+
+ <para>
+ Avez-vous spécifié le bon identifiant d'ensemble de réplication ?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I setDropSequence_int(): set % has origin at another node - submit this to that node</command>
+ </para>
+
+ <para>
+ Ce message semble assez évident.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect3>
+
+<sect3>
+<title>Problèmes lors de MOVE SET, FAILOVER, DROP NODE</title>
+
+<para>
+ Beaucoup de ces erreurs se produiront si vous soumettez un script &lslonik;
+ qui décrit une reconfiguration incompatible avec la configuration actuelle
+ de votre cluster. Ceci devrait vous faire dire : <quote>Heureusement
+ que &lslonik; a détecté ce problème à ma place !</quote>
+</para>
+
+<para>
+ D'autres messages se produisent lorsque &lslon; s'avertit lui-même qu'il va
+ s'arrêter. Tout <emphasis>devrait</emphasis> bien se passer lorsque vous le
+ redémarrez car il lira la nouvelle configuration lors de son redémarrage.
+</para>
+
+<para>
+ Hélas, quelques messages indiquent que <quote>quelque chose de mauvais est
+ arrivé</quote>, auquel cas la solution ne sera pas nécessairement simple.
+ Personne n'a dit que la réplication était facile...
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: DROP_NODE cannot initiate on the dropped node</command>
+ </para>
+
+ <para>
+ Vous devez préciser un paramètre EVENT NODE différent du nœud que
+ vous voulez supprimer.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: Node % is still configured as a data provider</command>
+ </para>
+
+ <para>
+ Vous ne pouvez pas supprimer un nœud qui est utilisé comme
+ fournisseur de données ; vous devez remodeler les abonnements pour
+ qu'aucun nœud ne soit dépendant de celui-ci.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: Node % is still origin of one or more sets</command>
+ </para>
+
+ <para>
+ Vous ne pouvez pas supprimer un nœud si c'est l'origine d'un
+ ensemble de réplication ! Utilisez d'abord <xref
+ linkend="stmtmoveset"/> ou <xref linkend="stmtfailover"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: cannot failover - node % has no path to the backup node</command>
+ </para>
+
+ <para>
+ Vous ne pouvez pas effectuer une bascule d'urgence vers un nœud qui
+ n'est pas connecté à tous les abonnés, au moins indirectement.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: cannot failover - node % is not subscribed to set %</command>
+ </para>
+
+ <para>
+ Vous ne pouvez pas faire une bascule d'urgence vers un nœud qui
+ n'est pas abonné à tous les ensembles de réplication essentiels.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: cannot failover - subscription for set % is not active</command>
+ </para>
+
+ <para>
+ Si l'abonnement a été configuré mais pas activé, la bascule d'urgence
+ n'est pas possible.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: cannot failover - node % is not a forwarder of set %</command>
+ </para>
+
+ <para>
+ Vous ne pouvez effectuer une bascule d'urgence ou une bascule contrôlée
+ que vers un nœud transmetteur.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>NOTICE: failedNode: set % has no other direct receivers - move now</command>
+ </para>
+
+ <para>
+ Si le nœud de sauvegarde est le seul abonné direct, alors la
+ situation est simplifiée... Pas besoin de remodeler les abonnements !
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>NOTICE: failedNode set % has other direct receivers - change providers only</command>
+ </para>
+
+ <para>
+ Dans ce cas, tous les abonnés directs sont redirigés vers le nœud
+ de sauvegarde et le nœud de sauvegarde est redirigé vers un autre
+ nœud pour qu'il puisse rattraper son retard.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>NOTICE: Slony-I: Please drop schema _ at CLUSTERNAME@</command>
+ </para>
+
+ <para>
+ Un nœud a été désinstallé ; vous pouvez supprimer le schéma...
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect3>
+
+<sect3>
+<title>Permutation des traces</title>
+
+<para>
+ Ces messages sont liés à la nouvelle fonctionnalité apparue dans la version
+ 1.2 qui permet à &slony1; de permuter périodiquement le stockage des données
+ entre <envar>sl_log_1</envar> et <envar>sl_log_2</envar>.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <command>Slony-I: Logswitch to sl_log_2 initiated'</command>
+ </para>
+
+ <para>
+ Ce message indique que &lslon; est en train de permuter vers cette table
+ de log.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>Slony-I: Logswitch to sl_log_1 initiated'</command>
+ </para>
+
+ <para>
+ Ce message indique que &lslon; est en train de permuter vers cette table
+ de log.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>Previous logswitch still in progress</command>
+ </para>
+
+ <para>
+ Une tentative de permutation a été faite alors qu'une permutation était
+ déjà en cours.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: remoteWorkerThread_%d: cannot détermine current log status</command>
+ </para>
+
+ <para>
+ La tentative de lecture dans la table sl_log_status, qui détermine si on
+ travaille sur <envar>sl_log_1</envar> ou <envar>sl_log_2</envar>, n'a
+ donné aucun résultat. Ce n'est pas bon signe car il doit y avoir des
+ données dans cette table... La réplication va probablement s'arrêter dans
+ peu de temps.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: current local log_status is %d</command>
+ </para>
+
+ <para>
+ Ce message indique la table (<envar>sl_log_1</envar> ou
+ <envar>sl_log_2</envar>) utilisée pour stocker les données de réplication.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect3>
+
+<sect3>
+<title>Divers</title>
+
+<para>
+ Les messages ci-dessous ne sont pas encore classés. Les auteurs de la
+ documentation ont encore du travail...
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <command>ERROR: Slonik version: @MODULEVERSION@ != Slony-I version in PG build %</command>
+ </para>
+
+ <para>
+ Ce message est produit par la fonction
+ <function>checkmoduleversion()</function> lorsqu'il y a un problème de
+ correspondance entre la version de &slony1; telle qu'elle est indiquée
+ par &lslonik; et la version avec laquelle &postgres; a été compilé.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: registry key % is not an int4 value</command>
+ </para>
+
+ <para>
+ Message produit par <function>registry_get_int4()</function>. Cela indique
+ que la valeur demandée semble être à NULL.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: registry key % is not a text value</command>
+ </para>
+
+ <para>
+ Message produit par <function>registry_get_text()</function>. Cela
+ indique que la valeur demandée semble être à NULL.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: registry key % is not a timestamp value</command>
+ </para>
+
+ <para>
+ Message produit par <function>registry_get_timestamp()</function>. Cela
+ indique que la valeur demandée semble être à NULL.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>NOTICE: Slony-I: cleanup stale sl_nodelock entry for pid=%</command>
+ </para>
+
+ <para>
+ Ceci se produit typiquement lorsqu'un &lslon; se lance après qu'un autre ait
+ échoué ; c'est un nettoyage de routine.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: This node is already initialized</command>
+ </para>
+
+ <para>
+ Ceci se produit typiquement lorsqu'on soumet une commande <xref
+ linkend="stmtstorenode"/> sur une nœud qui a déjà été configuré
+ avec le schéma &slony1;.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: node % not found</command>
+ </para>
+
+ <para>
+ Toute tentative pour marquer un nœud non listé localement comme
+ actif devrait échouer.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>ERROR: Slony-I: node % is already active</command>
+ </para>
+
+ <para>
+ Toute tentative pour marquer un nœud déjà marqué comme actif devrait
+ échouer.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG4: remoteWorkerThread_%d: added active set %d to provider %d</command>
+ </para>
+
+ <para>
+ Indique que cet ensemble est fourni par ce fournisseur.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: event %d ignored - unknown origin</command>
+ </para>
+
+ <para>
+ Ceci se produit probablement lorsque des événements arrivent avant
+ l'événement <command>STORE_NODE</command> qui annonce que le nouveau
+ nœud existe.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>WARN: remoteWorkerThread_%d: event %d ignored - origin inactive</command>
+ </para>
+
+ <para>
+ Ceci ce produit actuellement (2007) car la désactivation d'un
+ nœud n'est pas une fonctionnalité supportée.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: event %d ignored - duplicate </command>
+ </para>
+
+ <para>
+ Ceci devrait se produire lorsqu'une notification d'événement arrive en
+ provenance de deux sources.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>DEBUG2: remoteWorkerThread_%d: unknown node %d</command>
+ </para>
+
+ <para>
+ Ceci se produit lorsque le démon &lslon; n'est conscient de l'existence
+ de ce nœud. C'est probablement un signe que les requêtes
+ <command>STORE_NODE</command> ne se propagent pas.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect3>
+
+</sect2>
+
+</sect1>
Deleted: traduc/tags/slony_1_2_12/logshipping.xml
===================================================================
--- traduc/trunk/slony/logshipping.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/logshipping.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,704 +0,0 @@
-<?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 journalisation qui sont stockés dans
- un répertoire d'attente.
-</para>
-
-<para>
- Ces fichiers de journalisation 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'1 Go
- transportée par avion.
-</para>
-
-<para>
- Il y a plein de choses intéressantes à faire avec un tel flux de données,
- en particulier :
-
- <itemizedlist>
- <listitem>
- <para>
- Répliquer des nœuds qui <emphasis>ne peuvent pas</emphasis> être
- securisés ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- Répliquer dans des lieux où 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 fichiers de
- journalisation 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 nœud répliqué ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- C'est une 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>nœud
- 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 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 journalisation</quote> d'un
- ensemble de réplication donné ?
- </para>
- </question>
-
- <answer>
- <para>
- Chaque nœud 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 nœud abonné.
- </para>
- </note>
- </answer>
- </qandaentry>
-
- <qandaentry>
- <question>
- <para>
- Que se passe-t-il lors d'un <xref linkend="stmtfailover"/>/<xref
- linkend="stmtmoveset"/> ?
- </para>
- </question>
-
- <answer>
- <para>
- Rien de spécial. Tant que le nœud d'archivage reste un abonné,
- il continue à produire des fichiers de journalisation.
- </para>
- </answer>
-
- <answer>
- <warning>
- <para>
- Si le nœud d'archivage devient l'origine, il continuera à
- produire des fichiers de journalisation.
- </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 journalisation ?
- </para>
- </question>
-
- <answer>
- <para>
- Le nœud n'accepte plus les événements <command>SYNC</command>
- jusqu'à ce que le problème soit réglé. La base de donnée qui est
- dupliquée tombe é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 nœud abonné.
- </para>
-
- <para>
- Vous devez lancer le démon <application><link
- linkend="slon">slon</link></application> pour le nœud abonné
- avec le 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>nœud 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 avait 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 nœud abonné. En conséquence,
- vous devez avoir au moins un nœud <quote>standard</quote> ;
- vous ne pouvez pas avoir un cluster composé seulement d'une origine et
- d'un ensemble de <quote>nœuds de log shipping</quote>.
- </para>
- </answer>
-
- <answer>
- <para>
- Le <quote>nœud de log shipping</quote> traque la totalité du
- trafic allant vers un abonné. Vous pouvez séparer les choses lorsqu'il
- y a plusieurs ensembles de réplication.
- </para>
- </answer>
-
- <answer>
- <para>
- Actuellement, le <quote>nœud 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>
- Une bonne partie des types événements <emphasis>sont</emphasis> gérés
- afin que le log shipping puissent les traiter :
-
- <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 nœud 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és de manière
- <quote>appropriée</quote>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>SUBSCRIBE_SET</command>
- </para>
-
- <para>
- Malheureusement, des choses <quote>étranges</quote> surviennent
- 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 traité uniquement sur le nœud 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 nœud s'abonne à un ensemble donné via un fournisseur
- donné. <emphasis>Il ne copie pas les données !</emphasis>
- </para>
-
- <para>
- Le cœur du travail de souscription est réalisé par
- <command>ENABLE_SUBSCRIPTION</command>, qui est un événement
- déclenché sur le nœud local, et non pas dans la même
- séquence que les autres événements en provenance des autres
- nœuds (notament le fournisseur de données).
- </para>
-
- <para>
- Avec la modifications du traitement des fichiers de journalisation
- 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
- nœud 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 nœud de <quote>log
- shipping</quote> en un nœud &slony1; complètement fonctionnel sur
- lequel on pourrait basculer. Cela serait utile (par exemple) pour un
- cluster de 6 nœuds ; cela permettrait de commencer par
- créer un nœud abonné puis d'utiliser le log shipping pour
- construire les 4 autres nœuds en parallèle.
- </para>
-
- <para>
- Cette utilisation n'est pas possible, mais on peut ajouter la
- configuration &slony1; dans un nœud, et le promouvoir en tant
- que nouveau nœud. 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 ne 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> un <command>COMMIT</command> ou 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ées 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 l'horodatage 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>
- Cet horodatage représente la date où le <command>SYNC</command> a été
- déclenché sur le nœud 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 où vous voudrez appliquer toute les données d'une transaction de
- log shipping.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Vous pouvez trouver plus d'informations sur comment l'activité du
- nœud 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 fichiers de journalisation car
- leur règle de nommage est devenu plus compréhensible.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Les traces, sur le nœud de log shipping, qui indiquent le fichier
- de journalisation 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
- journalisation 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 nœuds qui composent le cluster. Tous les
- nœuds produisent régulièrement des événements <command>SYNC</command>,
- même s'ils ne sont pas le nœud origine, et le système de log
- shipping génère des logs pour ces événements.
- </para>
-
- <para>
- En conséquence, lorsqu'on cherche le fichier de journalisation suivant,
- il est nécessaire de chercher de la 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>
-</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 nœud 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
- nœud qui sera utilisé comme schéma source, et il liste les règles et
- les triggers, présents sur ce nœud, qui devraient être désactivés.
-</para>
-
-<para>
- Cela comprend le trigger <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>reste au premier plan (ne fonctionne pas en mode démon)</para></listitem>
- <listitem><para><option>w</option></para> <para>entre 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 fichiers de journalisation.
- </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 base de données</quote> afin de pouvoir
- parcourir un nœud à 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 journalisation
- 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 traité 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 at localhost ';</command></para>
-
- <para>
- La commande d'erreur indique quelle commande lancer lorsqu'une erreur est
- rencontrée. Tout l'archivage réalisé depuis le dernier archivage 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>
Copied: traduc/tags/slony_1_2_12/logshipping.xml (from rev 1244, traduc/trunk/slony/logshipping.xml)
===================================================================
--- traduc/tags/slony_1_2_12/logshipping.xml (rev 0)
+++ traduc/tags/slony_1_2_12/logshipping.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,676 @@
+<?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 journalisation qui sont stockés dans
+ un répertoire d'attente.
+</para>
+
+<para>
+ Ces fichiers de journalisation 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'1 Go
+ transportée par avion.
+</para>
+
+<para>
+ Il y a plein de choses intéressantes à faire avec un tel flux de données,
+ en particulier :
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Répliquer des nœuds qui <emphasis>ne peuvent pas</emphasis> être
+ securisés ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Répliquer dans des lieux où 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 fichiers de
+ journalisation 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 nœud répliqué ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ C'est une 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>nœud
+ 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 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 journalisation</quote> d'un
+ ensemble de réplication donné ?
+ </para>
+ </question>
+
+ <answer>
+ <para>
+ Chaque nœud 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 nœud abonné.
+ </para>
+ </note>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>
+ Que se passe-t-il lors d'un <xref linkend="stmtfailover"/>/<xref
+ linkend="stmtmoveset"/> ?
+ </para>
+ </question>
+
+ <answer>
+ <para>
+ Rien de spécial. Tant que le nœud d'archivage reste un abonné,
+ il continue à produire des fichiers de journalisation.
+ </para>
+ </answer>
+
+ <answer>
+ <warning>
+ <para>
+ Si le nœud d'archivage devient l'origine, il continuera à
+ produire des fichiers de journalisation.
+ </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 journalisation ?
+ </para>
+ </question>
+
+ <answer>
+ <para>
+ Le nœud n'accepte plus les événements <command>SYNC</command>
+ jusqu'à ce que le problème soit réglé. La base de donnée qui est
+ dupliquée tombe é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 nœud abonné.
+ </para>
+
+ <para>
+ Vous devez lancer le démon <application><link
+ linkend="slon">slon</link></application> pour le nœud abonné
+ avec le 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>nœud 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 avait 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 nœud abonné. En conséquence,
+ vous devez avoir au moins un nœud <quote>standard</quote> ;
+ vous ne pouvez pas avoir un cluster composé seulement d'une origine et
+ d'un ensemble de <quote>nœuds de log shipping</quote>.
+ </para>
+ </answer>
+
+ <answer>
+ <para>
+ Le <quote>nœud de log shipping</quote> traque la totalité du
+ trafic allant vers un abonné. Vous pouvez séparer les choses lorsqu'il
+ y a plusieurs ensembles de réplication.
+ </para>
+ </answer>
+
+ <answer>
+ <para>
+ Actuellement, le <quote>nœud 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>
+ Une bonne partie des types événements <emphasis>sont</emphasis> gérés
+ afin que le log shipping puissent les traiter :
+
+ <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 nœud 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és de manière
+ <quote>appropriée</quote>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>SUBSCRIBE_SET</command>
+ </para>
+
+ <para>
+ Malheureusement, des choses <quote>étranges</quote> surviennent
+ 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 traité uniquement sur le nœud 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 nœud s'abonne à un ensemble donné via un fournisseur
+ donné. <emphasis>Il ne copie pas les données !</emphasis>
+ </para>
+
+ <para>
+ Le cœur du travail de souscription est réalisé par
+ <command>ENABLE_SUBSCRIPTION</command>, qui est un événement
+ déclenché sur le nœud local, et non pas dans la même
+ séquence que les autres événements en provenance des autres
+ nœuds (notament le fournisseur de données).
+ </para>
+
+ <para>
+ Avec la modifications du traitement des fichiers de journalisation
+ 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
+ nœud 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 nœud de <quote>log
+ shipping</quote> en un nœud &slony1; complètement fonctionnel sur
+ lequel on pourrait basculer. Cela serait utile (par exemple) pour un
+ cluster de 6 nœuds ; cela permettrait de commencer par
+ créer un nœud abonné puis d'utiliser le log shipping pour
+ construire les 4 autres nœuds en parallèle.
+ </para>
+
+ <para>
+ Cette utilisation n'est pas possible, mais on peut ajouter la
+ configuration &slony1; dans un nœud, et le promouvoir en tant
+ que nouveau nœud. 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 ne 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> un <command>COMMIT</command> ou 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ées 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', '2005-09-23 18:37:40.206342');
+-- end of log archiving header
+ </programlisting>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Notez que l'en-tête inclut l'horodatage 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', '2005-09-23 19:01:31.267403');
+-- end of log archiving header</programlisting>
+ </para>
+
+ <para>
+ Cet horodatage représente la date où le <command>SYNC</command> a été
+ déclenché sur le nœud 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 où vous voudrez appliquer toute les données d'une transaction de
+ log shipping.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Vous pouvez trouver plus d'informations sur comment l'activité du
+ nœud 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 fichiers de journalisation car
+ leur règle de nommage est devenu plus compréhensible.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Les traces, sur le nœud de log shipping, qui indiquent le fichier
+ de journalisation 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
+ journalisation 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 nœuds qui composent le cluster. Tous les
+ nœuds produisent régulièrement des événements <command>SYNC</command>,
+ même s'ils ne sont pas le nœud origine, et le système de log
+ shipping génère des logs pour ces événements.
+ </para>
+
+ <para>
+ En conséquence, lorsqu'on cherche le fichier de journalisation suivant,
+ il est nécessaire de chercher de la 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>
+</itemizedlist>
+
+</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>reste au premier plan (ne fonctionne pas en mode démon)</para></listitem>
+ <listitem><para><option>w</option></para> <para>entre 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 fichiers de journalisation.
+ </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 base de données</quote> afin de pouvoir
+ parcourir un nœud à 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 journalisation
+ 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 traité 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 at localhost ';</command></para>
+
+ <para>
+ La commande d'erreur indique quelle commande lancer lorsqu'une erreur est
+ rencontrée. Tout l'archivage réalisé depuis le dernier archivage 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>
Deleted: traduc/tags/slony_1_2_12/maintenance.xml
===================================================================
--- traduc/trunk/slony/maintenance.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/maintenance.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,662 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="maintenance">
-<title>Maintenance</title>
-<indexterm><primary>maintenir &slony1;</primary></indexterm>
-
-<para>
- &slony1; effectue une grande partie de sa maintenance lui-même, dans un
- processus de <quote>nettoyage</quote> qui :
-
- <itemizedlist>
- <listitem>
- <para>
- supprime les anciennes données sur les différentes tables du schéma
- de <productname>Slony-I</productname>, notamment <xref
- linkend="table.sl-log-1"/>, <xref linkend="table.sl-log-2"/> et <xref
- linkend="table.sl-seqlog"/> ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- effectue un VACUUM sur certaines tables utilisées par &slony1;. À
- partir de la version 1.0.5, ceci inclut &pglistener; ; dans les
- versions antérieures, vous devez lancer souvent des VACUUM sur cette
- table, sinon vous verrez votre réplication ralentir car &slony1; lève
- beaucoup d'événements, qui mènent à ce que la table contienne de
- nombreuses lignes mortes.
- </para>
-
- <para>
- Avec certaines versions (la 1.1, peut-être la 1.0.5), il est possible
- de ne plus s'embarrasser avec les VACUUM sur ces tables si vous
- utilisez quelque chose comme <application>pg_autovacuum</application>
- pour gérer le nettoyage de ces tables. Malheureusement, il est possible
- que <application>pg_autovacuum</application> ne nettoie pas assez
- fréquemment, vous pourrez donc préférer utiliser les VACUUM internes.
- Nettoyer la table &pglistener; <quote>trop souvent</quote> est moins
- risqué que de ne pas la nettoyer assez.
- </para>
-
- <para>
- Malheureusement, si vous avez de longues transactions, les VACUUM ne
- peuvent pas nettoyer les lignes mortes qui sont plus récentes que les
- anciennes transactions toujours en cours. Ceci conduira en particulier
- à une forte croissance de &pglistener; et ralentira la réplication.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Le bogue <link linkend="dupkey">violation par clef dupliquée</link> a
- permis d'isoler des situations de concurrence dans &postgres;. Des
- problèmes subsistent notamment lorsque <command>VACUUM</command> ne
- réclame pas correctement l'espace menant à une corruption des index de
- type B-tree.
- </para>
-
- <para>
- Il peut être utile de lancer la commande <command>REINDEX TABLE
- sl_log_1;</command> périodiquement pour éviter ce problème.
- </para>
- </listitem>
-
- <listitem>
- <para>
- À partir de la version 1.2, la fonctionnalité <quote>log
- switching</quote> est arrivée ;de temps en temps, elle tente
- d'interchanger les données entre &sllog1; et &sllog2; afin de réaliser
- un <command>TRUNCATE</command> sur les <quote>plus vieilles</quote>
- données.
- </para>
-
- <para>
- Cela signifie que, de manière régulière, ces tables sont complètement
- nettoyées ce qui évite qu'elles ne grossissent trop lors d'une charge
- importante et qu'elles deviennent impossibles à nettoyer.
- </para>
- </listitem>
- </itemizedlist>
-</para>
-
-<sect2 id="maintenance-autovac">
-<title>Interaction avec l'autovacuum de &postgres;</title>
-<indexterm><primary>interaction avec autovacuum</primary></indexterm>
-
-<para>
- Les versions récentes de&postgres; proposent un processus
- <quote>autovacuum</quote> qui détecte les modifications sur les tables et
- la création de lignes mortes, puis nettoie ces tables, <quote>à la
- demande</quote>. On a constaté que cela peut interagir de manière négative
- avec la politique de VACUUM de &slony1; sur ces propres tables.
-</para>
-
-<para>
- &slony1; demande des VACUUM sur ses tables immédiatement après avoir complété
- les transactions qui sont sensées supprimer de vieilles données, ce qui est
- considéré comme le meilleur moment pour le faire. Il semble que l'autovacuum
- détecte les changements un peu trop tôt, et lance un VACUUM alors que les
- transactions ne sont pas terminées, ce qui est relativement inutile. Il
- apparaît préférable de configurer l'autovacuum pour éviter les tables de
- configuration gérées par &slony1;.
-</para>
-
-<para>
- La requête suivante identifie les tables que l'autovacuum ne doit pas traiter
- (remplacez le nom du cluster par celui de votre configuration locale) :
-</para>
-
-<programlisting>
-moncluster=# select oid, relname from pg_class where relnamespace = (select oid from pg_namespace where nspname = '_' || 'monCluster') and relhasindex;
- oid | relname
--------+--------------
- 17946 | sl_nodelock
- 17963 | sl_setsync
- 17994 | sl_trigger
- 17980 | sl_table
- 18003 | sl_sequence
- 17937 | sl_node
- 18034 | sl_listen
- 18017 | sl_path
- 18048 | sl_subscribe
- 17951 | sl_set
- 18062 | sl_event
- 18069 | sl_confirm
- 18074 | sl_seqlog
- 18078 | sl_log_1
- 18085 | sl_log_2
-(15 rows)
-</programlisting>
-
-<para>
- La requête suivante remplira la table <envar>pg_catalog.pg_autovacuum</envar>
- avec les informations de configuration adéquates :
- <command>INSERT INTO pg_catalog.pg_autovacuum (vacrelid, enabled)
- SELECT oid, 'f' FROM pg_catalog.pg_class
- WHERE relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = '_' || 'monCluster')
- AND relhasindex;</command>
-</para>
-
-</sect2>
-
-<sect2><title>Chiens de garde : garder les Slons en vie</title>
-<indexterm><primary>Chiens de garde pour garder en vie les démons slon</primary></indexterm>
-
-<para>
- Il y a deux scripts <quote>chiens de garde</quote> disponibles pour surveiller
- la réplication et relancer les processus <application>slon</application>
- lorsqu'ils meurent pour telle ou telle raison, par exemple une
- <quote>coupure</quote> réseau qui provoque une perte de connectivité.
-</para>
-
-<para>
- Ils pourraient vous être utiles...
-</para>
-
-<para>
- La <quote>meilleure et nouvelle</quote> façon de gérer les processus <xref
- linkend="slon"/> se fait via une combinaison de <xref linkend="mkslonconf"/>,
- qui crée un fichier de configuration pour chaque nœud d'un cluster, et
- <xref linkend="launchclusters"/> qui utilise ces fichiers de configuration.
-</para>
-
-<para>
- Cette approche est préférable aux anciens systèmes de <quote>chiens de
- garde</quote> car vous pouvez <quote>pointer</quote> précisément, dans chaque
- fichier de configurationn, le paramètrage désiré pour chaque nœud, sans
- avoir à vous préoccuper des options que le script chien de garde vous propose
- (ou pas). Ceci est particulièrement important si vous utilisez le <link
- linkend="logshipping">log shipping</link>, auquel cas oublier l'option
- <command>-a</command> peut ruiner le nœud destinataire du log shipping
- et ruiner par là-même votre journée.
-</para>
-
-</sect2>
-
-<sect2 id="gensync"><title>En parallèle aux chiens de garde :
-generate_syncs.sh</title>
-<indexterm><primary>générer des SYNC</primary></indexterm>
-
-<para>
- Un nouveau script est apparu dans &slony1; 1.1, il s'agit de
- <application>generate_syncs.sh</application>, qui est utilise dans les
- situations suivantes.
-</para>
-
-<para>
- Supposons que vous avez un serveur non fiable sur lequel le démon
- <application>slon</application> ne fonctionne pas en continu, en rentrant de
- week-end vous vous trouverez peut-être la situation suivante :
-</para>
-
-<para>
- Le vendredi soir, quelque chose s'est <quote>cassé</quote> et le temps que la
- base de donnée redémarre, aucun des démons <application>slon</application>
- n'a survécu. Votre application en ligne a ensuite connu trois jours
- de charge transactionnelle relativement forte.
-</para>
-
-<para>
- Lorsque vous redémarrez <application>slon</application> le lundi, il n'y a
- pas eu de synchronisation sur le maître depuis vendredi, ce qui fait que le
- prochain <quote>ensemble de SYNC</quote> comprendra toutes les modifications
- entre vendredi et lundi. Aïe !</para>
-
-<para>
- Si vous lancez <application>generate_syncs.sh</application> via une tache cron
- toute les 20 minutes, cela créera de force des événements
- <command>SYNC</command> sur l'origine, ce qui implique qu'entre vendredi et
- lundi, les nombreuses mises à jour seront découpées en plus de 100 ensembles
- de SYNC, qui pourront être appliqués de manière incrémentale, rendant la
- restauration moins déplaisante.
-</para>
-
-<para>
- Notez que si les <command>SYNC</command> <emphasis>sont</emphasis> exécutés
- régulièrement, ce scripts ne fera rien de particulier.
-</para>
-
-</sect2>
-
-<sect2><title>Tester l'état de &slony1;</title>
-<indexterm><primary>tester le statut du cluster</primary></indexterm>
-
-<para>
- Dans le répertoire <filename>tools</filename>, vous trouverez des scripts
- nommés <filename>test_slony_state.pl</filename> et
- <filename>test_slony_state-dbi.pl</filename>. Le premier utilise l'interface
- Perl/DBI, l'autre utilise l'interface PostgreSQL.
-</para>
-
-<para>
- Les deux font essentiellement la même chose, c'est-à-dire se connecter à un
- nœud &slony1; (celui de votre choix) et, à partir de là, détermine la
- liste des nœuds du cluster. Ensuite ils lancent une série de requêtes
- (en lecture seule, donc sans danger) afin de parcourir différentes tables à
- la recherche de différentes conditions susceptibles de revéler des problèmes,
- telles que :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Gonflement des tables comme pg_listener, sl_log_1, sl_log_2, sl_seqlog ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- Voies d'écoute ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- Analyse de la propagation des événements ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- Analyse de la propagation des confirmations.
- </para>
-
- <para>
- Si la communication est <emphasis>légèrement</emphasis> perturbée, la
- réplication peut fonctionner, mais les confirmations peuvent ne pas être
- retournées, ce qui empêche les nœuds de nettoyer les vieux
- événements et les anciennes données de réplication.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Lancer ce script une fois par heure ou une fois par jour peut vous aider à
- détecter les symptomes précurseurs de certains problèmes, avant même que
- cela conduise à une dégradation des performances.
-</para>
-
-</sect2>
-
-<sect2><title>Scripts de test de la réplication</title>
-
-<para>
- Dans le répertoire <filename>tools</filename>, on peut trouver quatre scripts
- qui peuvent être utilisés pour surveiller des instances &slony1; :
-
- <itemizedlist>
- <listitem>
- <para>
- <command>test_slony_replication</command> est un script Perl auquel
- vous pouvez passer les informations de connexion d'un nœud
- &slony1;. Il teste alors la table <xref linkend="table.sl-path"/> et
- d'autres informations sur ce nœud afin de déterminer la forme de
- l'ensemble de réplication choisi.
- </para>
-
- <para>
- Ensuite il injecte des requêtes de test dans la table nommée
- <envar>slony_test</envar> qui est définie comme ci-dessous, et qui doit
- être ajoutée à l'ensemble des tables répliquées :
-
- <programlisting>CREATE TABLE slony_test (
- description text,
- mod_date timestamp with time zone,
- "_Slony-I_testcluster_rowID" bigint DEFAULT nextval('"_testcluster".sl_rowid_seq'::text) NOT NULL
-);</programlisting>
- </para>
-
- <para>
- La dernière colonne de la table est définie par &slony1; comme une clé
- primaire manquante...
- </para>
-
- <para>
- Ce script génère une ligne de sortie pour chaque nœud &slony1;
- actif pour l'ensemble de réplication défini dans un fichier nommé
- <filename>cluster.fact.log</filename>.
- </para>
-
- <para>
- Il y a une option additionelle, <option>finalquery</option>, qui vous
- permet de passer une requête SQL spécifique à votre application pour
- déterminer l'état de votre application.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>log.pm</command> est un module Perl module qui gère les logs
- des scripts Perl.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>run_rep_tests.sh</command> est un script <quote>wrapper</quote>
- qui lance <command>test_slony_replication</command>.
- </para>
-
- <para>
- Si vous avez plusieurs clusters &slony1;, vous pouvez placer dans ce
- fichier la configuration pour se connecter à tous ces clusters.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>nagios_slony_test</command> est un script qui a été construit
- pour interroger les fichiers logs afin de pouvoir lancer le test de
- réplication régulièrement (nous le laissons toutes les six minutes) et
- qu'un outil de supervision tel que <ulink
- url="http://www.nagios.org/"> <productname>Nagios</productname></ulink>
- puisse utiliser le script pour surveiller l'état indiqué dans ces logs.
- </para>
-
- <para>
- Il semble plus efficace qu'une tache <application>cron</application>
- lance les tests et que <productname>Nagios</productname> vérifie le
- résultat plutôt que de voir <productname>Nagios</productname> lancer
- directement les tests. Ces tests peuvent vérifier l'ensemble du cluster
- &slony1; d'un seul coup, plutot que de voir <productname>Nagios</productname>
- provoquer des mises à jour en permanence.
- </para>
- </listitem>
- </itemizedlist>
-</para>
-
-</sect2>
-
-<sect2><title>Autres tests de réplication</title>
-<indexterm><primary>tester la réplication</primary></indexterm>
-
-<para>
- La méthodologie de la section précédente est conçu avec un vue pour minimiser
- le coût des requêtes de tests ; sur un cluster très chargé, supportant
- des centaines d'utilisateurs, le coût associé aux quelques requêtes de test
- n'est pas un point important et le temps de configuration des tables et des
- injecteurs de données est très élevé.
-</para>
-
-<para>
- Trois autres méthodes sont apparus pour analyser l'état de la
- réplication :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Pour un test orienté sur l'application, il est utile de créer une vue
- sur une table fréquemment mise à jour pour remonter des informations
- spécifiques à l'application.
- </para>
-
- <para>
- Par exemple, on peut chercher soit des statistiques sur les objets
- applicatifs les plus récents, soit les transactions de l'application.
- Par exemple :
- </para>
-
- <para>
- <command>CREATE VIEW replication_test AS
-SELECT now() - txn_time AS age, object_name
-FROM transaction_table
-ORDER BY txn_time DESC
-LIMIT 1;</command>
- </para>
-
- <para>
- <command>CREATE VIEW replication_test AS
-SELECT now() - created_on AS age, object_name
-FROM object_table
-ORDER BY id DESC
-LIMIT 1;</command>
- </para>
-
- <para>
- Il y a un inconvénient : cette approche nécessite que vous ayez une
- activité constante sur le système impliquant la création de nouvelles
- transactions de manière régulière. Si quelque chose ne fonctionne pas
- dans votre application, vous obtiendrez des fausses alertes en provenance
- de la réplication alors même que la réplication fonctionne correctement.
- </para>
- </listitem>
-
- <listitem>
- <para>
- La vue &slony1; nommée <envar>sl_status</envar> fournit des informations
- sur la synchronisation des différents nœuds. Son contenu n'est
- intéressant que sur les nœuds origine car les événements générés
- sur les autres nœuds peuvent généralement être ignorés.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Voir également la discussion sur <xref linkend="slonymrtg"/>.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-<sect2><title>Journaux applicatifs</title>
-<indexterm><primary>journaux applicatifs</primary></indexterm>
-
-<para>
- Les démons <xref linkend="slon"/> génère des journaux applicatifs plus ou
- moins verbeux, selon le niveau de débogage activé. Dans ce cas, vous
- pouvez :
-
- <itemizedlist>
- <listitem>
- <para>
- Utiliser un programme de rotation des journaux applicatifs comme
- <application>rotatelogs</application> d'<productname>Apache</productname>
- pour avoir une séquence de journaux applicatifs et éviter d'avoir des
- journaux trop gros ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- Purgez régulièrement les vieux journaux applicatifs.
- </para>
- </listitem>
- </itemizedlist>
-</para>
-
-</sect2>
-
-<sect2><title>Service</title>
-<indexterm><primary>service pour BSD </primary></indexterm>
-
-<sect3><title>slon</title>
-
-<para>
- Ce script crée un répertoire pour le service slon qui pourra être utilisé
- avec la commande svscan de daemontools. Ce script utilise multilog de manière
- très basique, ce qui semble être standard pour les installations daemontools
- / multilog. Si vous souhaitez une gestion intelligente des journaux applicatifs,
- consultez la section logrep ci-dessous. Actuellement, ce script a des
- possibilités de gestion d'erreurs très limitées.
-</para>
-
-<para>
- Pour les usages non-interactifs, configurez les variables d'environnement
- suivantes : <envar>BASEDIR</envar>, <envar>SYSUSR</envar>,
- <envar>PASSFILE</envar>, <envar>DBUSER</envar>, <envar>HOST</envar>,
- <envar>PORT</envar>, <envar>DATABASE</envar>, <envar>CLUSTER</envar> et
- <envar>SLON_BINARY</envar>. Si une seule de ces valeurs n'est pas définie,
- le script demande les informations de manière interactive.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <envar>BASEDIR</envar>, l'emplacement où la structure du répertoire du
- service slon sera créée. Il ne faut <emphasis>pas</emphasis> que ce soit
- le répertoire <filename>/var/service</filename> ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>SYSUSR</envar>, l'utilisateur unix qui lancera le processus slon
- (et multilog) ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>PASSFILE</envar>, l'emplacement du fichier
- <filename>.pgpass</filename> (par défaut
- <filename>~sysusr/.pgpass</filename>) ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>DBUSER</envar>, l'utilisateur postgres que slon doit utiliser (par
- défaut slony) ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>HOST</envar>, l'adresse du serveur ou slon doit se connecter (par
- défaut localhost) ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>PORT</envar>, le port de connexion (par défaut 5432) ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>DATABASE</envar>, la base de données sur laquelle slon se connecte
- (par défaut dbuser)
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>CLUSTER</envar>, le nom du cluster Slony1 (par défaut database) ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>SLON_BINARY</envar>, le chemin complet vers le binaire slon (par
- défaut <command>which slon</command>).
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-<sect3><title>logrep-mkservice.sh</title>
-
-<para>
- Ce script utilise <command>tail -F</command> pour extraire des données des
- journaux applicatifs en vous permettant d'utiliser des filtres multilog (via
- l'option CRITERIA) afin de créer des journaux de transactions spécifiques.
- Le but est de fournir un moyen de surveiller les journaux de transactions en
- temps réel en quête de données <quote>intéressante</quote> sans devoir
- modifier le journal applicatif initial ou gacher des ressources CPU/IO
- en parcourant les journaux régulièrement.
-</para>
-
-<para>
- Pour une utilisation non interactive, il faut configurer les variables :
- <envar>BASEDIR</envar>, <envar>SYSUSR</envar>, <envar>SOURCE</envar>,
- <envar>EXTENSION</envar> et <envar>CRITERIA</envar>. Si une seule de ces
- options n'est pas définie, le script demande interactivement les informations
- de configuration.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <envar>BASEDIR</envar>, l'emplacement où sera créée la structure du
- répertoire du service de logrep. Il ne faut <emphasis>pas</emphasis> que
- ce soit le répertoire <filename>/var/service</filename>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>SYSUSR</envar>, l'utilisateur unix qui lancera le service.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>SOURCE</envar>, le nom du service de log que vous voulez utiliser.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>EXTENSION</envar>, une balise pour différencier ce logrep de ceux
- qui utilisent la même source.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>CRITERIA</envar>, le filtre multilog que vous voulez utiliser.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Un exemple trivial consiste à produire un journal applicatif de tous les
- messages d'erreur slon qui pourraient être utilisés pour déclencher une
- alerte nagios :
- <command>EXTENSION='ERRORS'</command>
- <command>CRITERIA="'-*' '+* * ERROR*'"</command>
- (on relance la surveillance en déclenchant une rotation des journaux
- applicatifs avec <command>svc -a $svc_dir</command>)
-</para>
-
-<para>
- Une application plus intéressante est la surveillance de la progression
- d'une souscription d'un nœud :
- <command>EXTENSION='COPY'</command>
- <command>CRITERIA="'-*' '+* * ERROR*' '+* * WARN*' '+* * CONFIG enableSubscription*' '+* * DEBUG2 remoteWorkerThread_* prepare to copy table*' '+* * DEBUG2 remoteWorkerThread_* all tables for set * found on subscriber*' '+* * DEBUG2 remoteWorkerThread_* copy*' '+* * DEBUG2 remoteWorkerThread_* Begin COPY of table*' '+* * DEBUG2 remoteWorkerThread_* * bytes copied for table*' '+* * DEBUG2 remoteWorkerThread_* * seconds to*' '+* * DEBUG2 remoteWorkerThread_* set last_value of sequence*' '+* * DEBUG2 remoteWorkerThread_* copy_set*'"</command>
-</para>
-
-<para>
- Si vous avez une trace d'abonnement, alors il est facile de déterminer si un
- nœud donné est en train de réaliser une copie ou une autre activité de
- souscription. Si les journaux applicatifs ne sont pas vide et ne se terminent
- pas par <command>"CONFIG enableSubscription: sub_set:1"</command> (où 1 est
- le numéro d'ensemble de réplication que vous avez abonné) alors le slon est
- au milieu d'une copie initiale.
-</para>
-
-<para>
- Si vous surveillez l'horodatage de modification du journal applicatif de
- votre nœud primaire pour déterminer si le slon est tombé dans le coma,
- vérifier cette trace d'abonnement est un bon moyen d'éviter de stopper le
- nœud alors qu'un abonnement est en cours. En bonus, puisque les slons
- utilisent svscan, vous pouvez simplement détruire le fichier (via l'interface
- svc) et laisser svscan le recommencer plus tard. J'ai également découvert que
- les traces de COPY sont pratiques pour suivre de manière interactive
- l'activité des abonnements.
-</para>
-
-</sect3>
-
-</sect2>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/maintenance.xml (from rev 1244, traduc/trunk/slony/maintenance.xml)
===================================================================
--- traduc/tags/slony_1_2_12/maintenance.xml (rev 0)
+++ traduc/tags/slony_1_2_12/maintenance.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,414 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="maintenance">
+<title>Maintenance</title>
+<indexterm><primary>maintenir &slony1;</primary></indexterm>
+
+<para>
+ &slony1; effectue une grande partie de sa maintenance lui-même, dans un
+ processus de <quote>nettoyage</quote> qui :
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ supprime les anciennes données sur les différentes tables du schéma
+ de <productname>Slony-I</productname>, notamment <xref
+ linkend="table.sl-log-1"/>, <xref linkend="table.sl-log-2"/> et <xref
+ linkend="table.sl-seqlog"/> ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ effectue un VACUUM sur certaines tables utilisées par &slony1;. À
+ partir de la version 1.0.5, ceci inclut &pglistener; ; dans les
+ versions antérieures, vous devez lancer souvent des VACUUM sur cette
+ table, sinon vous verrez votre réplication ralentir car &slony1; lève
+ beaucoup d'événements, qui mènent à ce que la table contienne de
+ nombreuses lignes mortes.
+ </para>
+
+ <para>
+ Avec certaines versions (la 1.1, peut-être la 1.0.5), il est possible
+ de ne plus s'embarrasser avec les VACUUM sur ces tables si vous
+ utilisez quelque chose comme <application>pg_autovacuum</application>
+ pour gérer le nettoyage de ces tables. Malheureusement, il est possible
+ que <application>pg_autovacuum</application> ne nettoie pas assez
+ fréquemment, vous pourrez donc préférer utiliser les VACUUM internes.
+ Nettoyer la table &pglistener; <quote>trop souvent</quote> est moins
+ risqué que de ne pas la nettoyer assez.
+ </para>
+
+ <para>
+ Malheureusement, si vous avez de longues transactions, les VACUUM ne
+ peuvent pas nettoyer les lignes mortes qui sont plus récentes que les
+ anciennes transactions toujours en cours. Ceci conduira en particulier
+ à une forte croissance de &pglistener; et ralentira la réplication.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Le bogue <link linkend="dupkey">violation par clef dupliquée</link> a
+ permis d'isoler des situations de concurrence dans &postgres;. Des
+ problèmes subsistent notamment lorsque <command>VACUUM</command> ne
+ réclame pas correctement l'espace menant à une corruption des index de
+ type B-tree.
+ </para>
+
+ <para>
+ Il peut être utile de lancer la commande <command>REINDEX TABLE
+ sl_log_1;</command> périodiquement pour éviter ce problème.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ À partir de la version 1.2, la fonctionnalité <quote>log
+ switching</quote> est arrivée ;de temps en temps, elle tente
+ d'interchanger les données entre &sllog1; et &sllog2; afin de réaliser
+ un <command>TRUNCATE</command> sur les <quote>plus vieilles</quote>
+ données.
+ </para>
+
+ <para>
+ Cela signifie que, de manière régulière, ces tables sont complètement
+ nettoyées ce qui évite qu'elles ne grossissent trop lors d'une charge
+ importante et qu'elles deviennent impossibles à nettoyer.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
+
+<sect2><title>Chiens de garde : garder les Slons en vie</title>
+<indexterm><primary>Chiens de garde pour garder en vie les démons slon</primary></indexterm>
+
+<para>
+ Il y a deux scripts <quote>chiens de garde</quote> disponibles pour surveiller
+ la réplication et relancer les processus <application>slon</application>
+ lorsqu'ils meurent pour telle ou telle raison, par exemple une
+ <quote>coupure</quote> réseau qui provoque une perte de connectivité.
+</para>
+
+<para>
+ Ils pourraient vous être utiles...
+</para>
+
+<para>
+ La <quote>meilleure et nouvelle</quote> façon de gérer les processus <xref
+ linkend="slon"/> se fait via une combinaison de <xref linkend="mkslonconf"/>,
+ qui crée un fichier de configuration pour chaque nœud d'un cluster, et
+ <xref linkend="launchclusters"/> qui utilise ces fichiers de configuration.
+</para>
+
+<para>
+ Cette approche est préférable aux anciens systèmes de <quote>chiens de
+ garde</quote> car vous pouvez <quote>pointer</quote> précisément, dans chaque
+ fichier de configurationn, le paramètrage désiré pour chaque nœud, sans
+ avoir à vous préoccuper des options que le script chien de garde vous propose
+ (ou pas). Ceci est particulièrement important si vous utilisez le <link
+ linkend="logshipping">log shipping</link>, auquel cas oublier l'option
+ <command>-a</command> peut ruiner le nœud destinataire du log shipping
+ et ruiner par là-même votre journée.
+</para>
+
+</sect2>
+
+<sect2 id="gensync"><title>En parallèle aux chiens de garde :
+generate_syncs.sh</title>
+
+<para>
+ Un nouveau script est apparu dans &slony1; 1.1, il s'agit de
+ <application>generate_syncs.sh</application>, qui est utilise dans les
+ situations suivantes.
+</para>
+
+<para>
+ Supposons que vous avez un serveur non fiable sur lequel le démon
+ <application>slon</application> ne fonctionne pas en continu, en rentrant de
+ week-end vous vous trouverez peut-être la situation suivante :
+</para>
+
+<para>
+ Le vendredi soir, quelque chose s'est <quote>cassé</quote> et le temps que la
+ base de donnée redémarre, aucun des démons <application>slon</application>
+ n'a survécu. Votre application en ligne a ensuite connu trois jours
+ de charge transactionnelle relativement forte.
+</para>
+
+<para>
+ Lorsque vous redémarrez <application>slon</application> le lundi, il n'y a
+ pas eu de synchronisation sur le maître depuis vendredi, ce qui fait que le
+ prochain <quote>ensemble de SYNC</quote> comprendra toutes les modifications
+ entre vendredi et lundi. Aïe !</para>
+
+<para>
+ Si vous lancez <application>generate_syncs.sh</application> via une tache cron
+ toute les 20 minutes, cela créera de force des événements
+ <command>SYNC</command> sur l'origine, ce qui implique qu'entre vendredi et
+ lundi, les nombreuses mises à jour seront découpées en plus de 100 ensembles
+ de SYNC, qui pourront être appliqués de manière incrémentale, rendant la
+ restauration moins déplaisante.
+</para>
+
+<para>
+ Notez que si les <command>SYNC</command> <emphasis>sont</emphasis> exécutés
+ régulièrement, ce scripts ne fera rien de particulier.
+</para>
+
+</sect2>
+
+<sect2><title>Tester l'état de &slony1;</title>
+<indexterm><primary>tester le statut du cluster</primary></indexterm>
+
+<para>
+ Dans le répertoire <filename>tools</filename>, vous trouverez des scripts
+ nommés <filename>test_slony_state.pl</filename> et
+ <filename>test_slony_state-dbi.pl</filename>. Le premier utilise l'interface
+ Perl/DBI, l'autre utilise l'interface PostgreSQL.
+</para>
+
+<para>
+ Les deux font essentiellement la même chose, c'est-à-dire se connecter à un
+ nœud &slony1; (celui de votre choix) et, à partir de là, détermine la
+ liste des nœuds du cluster. Ensuite ils lancent une série de requêtes
+ (en lecture seule, donc sans danger) afin de parcourir différentes tables à
+ la recherche de différentes conditions susceptibles de revéler des problèmes,
+ telles que :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Gonflement des tables comme pg_listener, sl_log_1, sl_log_2, sl_seqlog ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Voies d'écoute ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Analyse de la propagation des événements ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Analyse de la propagation des confirmations.
+ </para>
+
+ <para>
+ Si la communication est <emphasis>légèrement</emphasis> perturbée, la
+ réplication peut fonctionner, mais les confirmations peuvent ne pas être
+ retournées, ce qui empêche les nœuds de nettoyer les vieux
+ événements et les anciennes données de réplication.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Lancer ce script une fois par heure ou une fois par jour peut vous aider à
+ détecter les symptomes précurseurs de certains problèmes, avant même que
+ cela conduise à une dégradation des performances.
+</para>
+
+</sect2>
+
+<sect2><title>Scripts de test de la réplication</title>
+
+<para>
+ Dans le répertoire <filename>tools</filename>, on peut trouver quatre scripts
+ qui peuvent être utilisés pour surveiller des instances &slony1; :
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <command>test_slony_replication</command> est un script Perl auquel
+ vous pouvez passer les informations de connexion d'un nœud
+ &slony1;. Il teste alors la table <xref linkend="table.sl-path"/> et
+ d'autres informations sur ce nœud afin de déterminer la forme de
+ l'ensemble de réplication choisi.
+ </para>
+
+ <para>
+ Ensuite il injecte des requêtes de test dans la table nommée
+ <envar>slony_test</envar> qui est définie comme ci-dessous, et qui doit
+ être ajoutée à l'ensemble des tables répliquées :
+
+ <programlisting>CREATE TABLE slony_test (
+ description text,
+ mod_date timestamp with time zone,
+ "_Slony-I_testcluster_rowID" bigint DEFAULT nextval('"_testcluster".sl_rowid_seq'::text) NOT NULL
+);</programlisting>
+ </para>
+
+ <para>
+ La dernière colonne de la table est définie par &slony1; comme une clé
+ primaire manquante...
+ </para>
+
+ <para>
+ Ce script génère une ligne de sortie pour chaque nœud &slony1;
+ actif pour l'ensemble de réplication défini dans un fichier nommé
+ <filename>cluster.fact.log</filename>.
+ </para>
+
+ <para>
+ Il y a une option additionelle, <option>finalquery</option>, qui vous
+ permet de passer une requête SQL spécifique à votre application pour
+ déterminer l'état de votre application.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>log.pm</command> est un module Perl module qui gère les logs
+ des scripts Perl.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>run_rep_tests.sh</command> est un script <quote>wrapper</quote>
+ qui lance <command>test_slony_replication</command>.
+ </para>
+
+ <para>
+ Si vous avez plusieurs clusters &slony1;, vous pouvez placer dans ce
+ fichier la configuration pour se connecter à tous ces clusters.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>nagios_slony_test</command> est un script qui a été construit
+ pour interroger les fichiers logs afin de pouvoir lancer le test de
+ réplication régulièrement (nous le laissons toutes les six minutes) et
+ qu'un outil de supervision tel que <ulink
+ url="http://www.nagios.org/"> <productname>Nagios</productname></ulink>
+ puisse utiliser le script pour surveiller l'état indiqué dans ces logs.
+ </para>
+
+ <para>
+ Il semble plus efficace qu'une tache <application>cron</application>
+ lance les tests et que <productname>Nagios</productname> vérifie le
+ résultat plutôt que de voir <productname>Nagios</productname> lancer
+ directement les tests. Ces tests peuvent vérifier l'ensemble du cluster
+ &slony1; d'un seul coup, plutot que de voir <productname>Nagios</productname>
+ provoquer des mises à jour en permanence.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
+
+</sect2>
+
+<sect2><title>Autres tests de réplication</title>
+
+<para>
+ La méthodologie de la section précédente est conçu avec un vue pour minimiser
+ le coût des requêtes de tests ; sur un cluster très chargé, supportant
+ des centaines d'utilisateurs, le coût associé aux quelques requêtes de test
+ n'est pas un point important et le temps de configuration des tables et des
+ injecteurs de données est très élevé.
+</para>
+
+<para>
+ Trois autres méthodes sont apparus pour analyser l'état de la
+ réplication :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Pour un test orienté sur l'application, il est utile de créer une vue
+ sur une table fréquemment mise à jour pour remonter des informations
+ spécifiques à l'application.
+ </para>
+
+ <para>
+ Par exemple, on peut chercher soit des statistiques sur les objets
+ applicatifs les plus récents, soit les transactions de l'application.
+ Par exemple :
+ </para>
+
+ <para>
+ <command>CREATE VIEW replication_test AS
+SELECT now() - txn_time AS age, object_name
+FROM transaction_table
+ORDER BY txn_time DESC
+LIMIT 1;</command>
+ </para>
+
+ <para>
+ <command>CREATE VIEW replication_test AS
+SELECT now() - created_on AS age, object_name
+FROM object_table
+ORDER BY id DESC
+LIMIT 1;</command>
+ </para>
+
+ <para>
+ Il y a un inconvénient : cette approche nécessite que vous ayez une
+ activité constante sur le système impliquant la création de nouvelles
+ transactions de manière régulière. Si quelque chose ne fonctionne pas
+ dans votre application, vous obtiendrez des fausses alertes en provenance
+ de la réplication alors même que la réplication fonctionne correctement.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ La vue &slony1; nommée <envar>sl_status</envar> fournit des informations
+ sur la synchronisation des différents nœuds. Son contenu n'est
+ intéressant que sur les nœuds origine car les événements générés
+ sur les autres nœuds peuvent généralement être ignorés.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Voir également la discussion sur <xref linkend="slonymrtg"/>.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2><title>Journaux applicatifs</title>
+<indexterm><primary>journaux applicatifs</primary></indexterm>
+
+<para>
+ Les démons <xref linkend="slon"/> génère des journaux applicatifs plus ou
+ moins verbeux, selon le niveau de débogage activé. Dans ce cas, vous
+ pouvez :
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Utiliser un programme de rotation des journaux applicatifs comme
+ <application>rotatelogs</application> d'<productname>Apache</productname>
+ pour avoir une séquence de journaux applicatifs et éviter d'avoir des
+ journaux trop gros ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Purgez régulièrement les vieux journaux applicatifs.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
+
+</sect2>
+
+</sect1>
Deleted: traduc/tags/slony_1_2_12/monitoring.xml
===================================================================
--- traduc/trunk/slony/monitoring.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/monitoring.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,349 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="monitoring">
-<title>Surveillance</title>
-<indexterm><primary>Surveiller &slony1;</primary></indexterm>
-
-<sect2>
-<title>Tester la replication avec &nagios;</title>
-<indexterm><primary>&nagios; pour surveiller la réplication</primary></indexterm>
-
-<para>
- Le script <command>psql_replication_check.pl</command>, qui se trouve dans le
- répertoire <filename>tools</filename>, regroupe les meilleures tentatives de
- de tests utilisables par le système de surveillance <ulink
- url="http://www.nagios.org/">&nagios;</ulink>.
-</para>
-
-<para>
- Un script antérieur, nommé <filename>test_slony_replication.pl</filename>,
- utilisait une approche <quote>intelligente</quote> : un <quote>script de
- test</quote> est exécuté périodiquement et se déploie à travers les
- configurations &slony1; pour trouver l'origine et les abonnés, injecte un
- changement et observe sa propagation à travers le système. Il présentait deux
- problèmes :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- En cas de problème de connectique impactant le nœud qui jouait ce
- test, c'est l'ensemble de réplication qui semblait détruite. De plus,
- cette stratégie de surveillance est très fragile et dépend de nombreuses
- conditions d'erreurs.
- </para>
- </listitem>
-
- <listitem>
- <para>
- &nagios; n'a pas la possibilité de profiter de l'
- <quote>intelligence</quote> d'une exploration automatique d'un ensemble
- de nœuds. Vous devez mettre en place des règles de surveillance
- &nagios; pour chaque nœud.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Le nouveau script, <command>psql_replication_check.pl</command>, utilise une
- approche minimaliste qui suppose que le système est un système en ligne
- recevant un <quote>trafic</quote> régulier, et vous permet de définir une vue
- spécifique pour le test de réplication appelée
- <envar>replication_status</envar> qui doit contenir des mises à jour
- régulières. Cette vue regarde simplement la dernière
- <quote>transaction</quote> sur le nœud, et liste son horodatage, son
- âge ainsi que quelques informations sur l'application qui peuvent être
- utiles.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Pour un système d'inventaire, cela pourrait être le numéro de l'ordre
- effectué le plus récemment.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Pour un serveur de nom de domaines, cela peut être le nom du dernier
- domaine créé.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Une instance du script doit être exécutée sur chaque nœud
- surveillé ; c'est ainsi que &nagios; fonctionne.
-</para>
-
-</sect2>
-
-<sect2 id="slonymrtg">
-<title>Surveiller &slony1; avec MRTG</title>
-<indexterm><primary>Utiliser MRTG pour surveiller la réplication</primary></indexterm>
-
-<para>
- Un utilisateur a expliqué sur la liste de discussion de &slony1; comment
- configurer <ulink url="http://people.ee.ethz.ch/~oetiker/webtools/mrtg/">
- <application>MRTG</application></ulink> (acronyme de « Multi Router
- Traffic Grapher ») pour surveiller une réplication &slony1;.
-</para>
-
-<para>
- [...] puisque j'utilise <application>MRTG</application> pour visualiser les
- données depuis plusieurs serveurs, j'utilise SNMP
- (<application>net-snmp</application> pour être exact). Pour un serveur de
- bases de données, j'ai ajouté la ligne suivante à la configuration de
- <application>snmpd</application> :
-</para>
-
-<programlisting>
-exec replicationLagTime /cvs/scripts/snmpReplicationLagTime.sh 2
-</programlisting>
-
-<para>
- avec <filename>/cvs/scripts/snmpReplicationLagTime.sh</filename> contenant
- ceci :
-</para>
-
-<programlisting>
-#!/bin/bash
-/home/pgdba/work/bin/psql -U pgdba -h 127.0.0.1 -p 5800 -d _DBNAME_ -qAt -c
-"select cast(extract(epoch from st_lag_time) as int8) FROM _irr.sl_status
-WHERE st_received = $1"
-</programlisting>
-
-<para>
- Ensuite, dans la configuration de mrtg, j'ai ajouté la cible suivante :
-</para>
-
-<programlisting>
-Target[db_replication_lagtime]:extOutput.3&extOutput.3:public at db::30:::
-MaxBytes[db_replication_lagtime]: 400000000
-Title[db_replication_lagtime]: db: replication lag time
-PageTop[db_replication_lagtime]: <H1>db: replication lag time</H1>
-Options[db_replication_lagtime]: gauge,nopercent,growright
-</programlisting>
-
-<para>
- De son coté, Ismail Yenigul propose une méthode pour surveiller
- &slony1; en utilisant <application>MRTG</application> sans installer
- <application>SNMPD</application>.
-</para>
-
-<para>
- Voici sa configuration MRTG :
-</para>
-
-<programlisting>
-Target[db_replication_lagtime]:`/bin/snmpReplicationLagTime.sh 2`
-MaxBytes[db_replication_lagtime]: 400000000
-Title[db_replication_lagtime]: db: replication lag time
-PageTop[db_replication_lagtime]: <H1>db: replication lag time</H1>
-Options[db_replication_lagtime]: gauge,nopercent,growright
-</programlisting>
-
-<para>
- Et voici sa version modifiée du script :
-</para>
-
-<programlisting>
-# cat /bin/snmpReplicationLagTime.sh
-#!/bin/bash
-
-output=`/usr/bin/psql -U slony -h 192.168.1.1 -d endersysecm -qAt -c
-"select cast(extract(epoch from st_lag_time) as int8) FROM _mycluster.sl_status WHERE st_received = $1"`
-echo $output
-echo $output
-echo
-echo
-# end of script#
-</programlisting>
-
-<note>
- <para>
- MRTG attend quatre lignes en provenance du script. Puisque le script n'en
- fournit que deux, la sortie doit être prolongée de deux lignes.
- </para>
-</note>
-
-</sect2>
-
-<sect2 id="testslonystate">
-<title>test_slony_state</title>
-<indexterm><primary>script test_slony_state pour tester l'état de la réplication</primary></indexterm>
-
-<para>
- Ce script effectue différents analyses sur l'état d'un cluster &slony1;.
-</para>
-
-<para>
- Vous devez spécifier les arguments tels que la <option>base de
- données</option>, l'<option>hôte</option>, l'<option>utilisateur</option>,
- le <option>cluster</option>, le <option>mot de passe</option> et le
- <option>port</option> afin de se connecter à n'importe quel nœud du
- cluster. Vous devez également préciser une commande <option>mailprog</option>
- (qui doit être une commande équivalente à la commande
- <productname>Unix</productname> <application>mailx</application>) et une
- destination pour le courrier.
-</para>
-
-<para>
- Par ailleurs, vous spécifiez les paramètres de connexion aux bases de données
- via les variables d'environnement utilisées par
- <application>libpq</application>, <emphasis>par exemple</emphasis> :
- <envar>PGPORT</envar>, <envar>PGDATABASE</envar>, <envar>PGUSER</envar>,
- <envar>PGSERVICE</envar> et ainsi de suite.
-</para>
-
-<para>
- Le script se promène à travers <xref linkend="table.sl-path"/> pour trouver
- tous les nœuds du cluster et dans les DSNs qui lui permettront de se
- connecter à chaque nœud.
-</para>
-
-<para>
- Pour chaque nœud, le script examine l'état des données suivantes :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Vérification de <xref linkend="table.sl-listen"/> à la recherche de
- problèmes <quote>déterminés analytiquement</quote>. Cela liste les voies
- de communication qui ne sont pas couvertes.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Effectuer un résumé des événements sur le nœud d'origine.
- </para>
-
- <para>
- Si un nœud n'a pas soumis un événement depuis longtemps, il y a
- certainement un problème.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Vérification de <quote>l'âge</quote> de la table <xref
- linkend="table.sl-confirm"/>.
- </para>
-
- <para>
- Si un ou plusieurs nœuds du cluster n'ont pas envoyé de rapport
- récemment, alors cela peut conduire à l'absence de nettoyage dans
- certaines tables comme <xref linkend="table.sl-log-1"/> et <xref
- linkend="table.sl-seqlog"/>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Vérifications des transactions longues.
- </para>
-
- <para>
- Ceci ne fonctionne correctement que si le collecteur de statistique est
- configuré pour collecter les requêtes, c'est-à-dire l'option
- <option>stats_command_string = true</option> est présente dans
- <filename>postgresql.conf</filename>.
- </para>
-
- <para>
- Si des applications buggées conservent des connexions ouvertes, ce script
- devrait les trouver.
- </para>
-
- <para>
- Si des applications buggées conservent des connexions ouvertes, plusieurs
- effets négatifs sont à prévoir tels que <link
- linkend="longtxnsareevil">ceux décrits dans la FAQ</link>.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Ce script fait des diagnostiques basés sur des paramètres définis dans le
- script ; si vous n'aimez pas les valeurs par défaut, modifiez-les !
-</para>
-
-</sect2>
-
-<sect2 id="search-logs">
-<title><command>search-logs.sh</command></title>
-<indexterm><primary>chercher dans les journaux applicatifs &slony1; avec search-logs.sh</primary></indexterm>
-
-<para>
- Ce script est construit pour chercher dans les journaux applicatifs &slony1;,
- à un emplacement donné (<envar>LOGHOME</envar>), en se basant à la fois
- sur les conventions de nommage utilisées par les systèmes <xref
- linkend="launchclusters"/> et <xref linkend="slonwatchdog"/> lors du
- démarrage des processus &lslon;.
-</para>
-
-<para>
- Si des erreurs sont trouvées, elles sont listées pour chaque fichier et
- transmises par courriel à un utilisateur spécifié
- (<envar>LOGRECIPIENT</envar>) ; si aucun courriel n'est spécifié, le
- résultat est affiché sur la sortie standard.
-</para>
-
-<para>
- <envar>LOGTIMESTAMP</envar> permet de rechercher à partir de cette (plutôt
- sur la dernière heure).
-</para>
-
-<para>
- Un administrateur peut exécuter ce script une fois par heure pour surveiller
- les problèmes de réplication.
-</para>
-
-</sect2>
-
-<sect2 id="wikigen">
-<title>Produire un rapport de surveillance au format MediaWiki</title>
-<indexterm><primary>générer la documentation Wiki d'un cluster</primary></indexterm>
-
-<para>
- Le script <filename>mkmediawiki.pl </filename>, situé dans
- <filename>tools</filename>, peut être utilisé pour générer un rapport de
- surveillance du cluster compatible avec le populaire logiciel <ulink
- url="http://www.mediawiki.org/">MediaWiki</ulink>. Notons que l'option
- <option>--categories</option> permet à l'utilisateur de préciser un ensemble
- de catégories (séparées par une virgule) qui seront associées aux résultats.
- Si vous avez passer l'option <option>--categories=slony1</option> à une série
- de clusters &slony1;, cela entraînera la création d'une page catégorie
- répertoriant l'ensemble des clusters &slony1;.
-</para>
-
-<para>
- On pourra utiliser le commande ainsi :
-</para>
-
-<screen>
-~/logtail.en> mvs login -d mywiki.example.info -u "Chris Browne" -p `cat ~/.wikipass` -w wiki/index.php
-Doing login with host: logtail and lang: en
-~/logtail.en> perl $SLONYHOME/tools/mkmediawiki.pl --host localhost --database slonyregress1 --cluster slony_regress1 --categories=Slony-I > Slony_replication.wiki
-~/logtail.en> mvs commit -m "More sophisticated generated Slony-I cluster docs" Slony_replication.wiki
-Doing commit Slony_replication.wiki with host: logtail and lang: en
-</screen>
-
-<para>
- Notons que <command>mvs</command> est un client Mediawiki écrit en Perl ;
- sur <ulink url="http://www.debian.org/">Debian GNU/Linux</ulink>, le paquet
- associé est nommé <application>libwww-mediawiki-client-perl</application> ;
- d'autres systèmes disposent probablement d'une version packagée sous un nom
- similaire.
-</para>
-
-</sect2>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/monitoring.xml (from rev 1244, traduc/trunk/slony/monitoring.xml)
===================================================================
--- traduc/tags/slony_1_2_12/monitoring.xml (rev 0)
+++ traduc/tags/slony_1_2_12/monitoring.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,344 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="monitoring">
+<title>Surveillance</title>
+<indexterm><primary>Surveiller &slony1;</primary></indexterm>
+
+<sect2>
+<title>Tester la replication avec &nagios;</title>
+<indexterm><primary>&nagios; pour surveiller la réplication</primary></indexterm>
+
+<para>
+ Le script <command>psql_replication_check.pl</command>, qui se trouve dans le
+ répertoire <filename>tools</filename>, regroupe les meilleures tentatives de
+ de tests utilisables par le système de surveillance <ulink
+ url="http://www.nagios.org/">&nagios;</ulink>.
+</para>
+
+<para>
+ Un script antérieur, nommé <filename>test_slony_replication.pl</filename>,
+ utilisait une approche <quote>intelligente</quote> : un <quote>script de
+ test</quote> est exécuté périodiquement et se déploie à travers les
+ configurations &slony1; pour trouver l'origine et les abonnés, injecte un
+ changement et observe sa propagation à travers le système. Il présentait deux
+ problèmes :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ En cas de problème de connectique impactant le nœud qui jouait ce
+ test, c'est l'ensemble de réplication qui semblait détruite. De plus,
+ cette stratégie de surveillance est très fragile et dépend de nombreuses
+ conditions d'erreurs.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ &nagios; n'a pas la possibilité de profiter de l'
+ <quote>intelligence</quote> d'une exploration automatique d'un ensemble
+ de nœuds. Vous devez mettre en place des règles de surveillance
+ &nagios; pour chaque nœud.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Le nouveau script, <command>psql_replication_check.pl</command>, utilise une
+ approche minimaliste qui suppose que le système est un système en ligne
+ recevant un <quote>trafic</quote> régulier, et vous permet de définir une vue
+ spécifique pour le test de réplication appelée
+ <envar>replication_status</envar> qui doit contenir des mises à jour
+ régulières. Cette vue regarde simplement la dernière
+ <quote>transaction</quote> sur le nœud, et liste son horodatage, son
+ âge ainsi que quelques informations sur l'application qui peuvent être
+ utiles.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Pour un système d'inventaire, cela pourrait être le numéro de l'ordre
+ effectué le plus récemment.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Pour un serveur de nom de domaines, cela peut être le nom du dernier
+ domaine créé.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Une instance du script doit être exécutée sur chaque nœud
+ surveillé ; c'est ainsi que &nagios; fonctionne.
+</para>
+
+</sect2>
+
+<sect2 id="slonymrtg">
+<title>Surveiller &slony1; avec MRTG</title>
+<indexterm><primary>Utiliser MRTG pour surveiller la réplication</primary></indexterm>
+
+<para>
+ Un utilisateur a expliqué sur la liste de discussion de &slony1; comment
+ configurer <ulink url="http://people.ee.ethz.ch/~oetiker/webtools/mrtg/">
+ <application>MRTG</application></ulink> (acronyme de « Multi Router
+ Traffic Grapher ») pour surveiller une réplication &slony1;.
+</para>
+
+<para>
+ [...] puisque j'utilise <application>MRTG</application> pour visualiser les
+ données depuis plusieurs serveurs, j'utilise SNMP
+ (<application>net-snmp</application> pour être exact). Pour un serveur de
+ bases de données, j'ai ajouté la ligne suivante à la configuration de
+ <application>snmpd</application> :
+</para>
+
+<programlisting>
+exec replicationLagTime /cvs/scripts/snmpReplicationLagTime.sh 2
+</programlisting>
+
+<para>
+ avec <filename>/cvs/scripts/snmpReplicationLagTime.sh</filename> contenant
+ ceci :
+</para>
+
+<programlisting>
+#!/bin/bash
+/home/pgdba/work/bin/psql -U pgdba -h 127.0.0.1 -p 5800 -d _DBNAME_ -qAt -c
+"select cast(extract(epoch from st_lag_time) as int8) FROM _irr.sl_status
+WHERE st_received = $1"
+</programlisting>
+
+<para>
+ Ensuite, dans la configuration de mrtg, j'ai ajouté la cible suivante :
+</para>
+
+<programlisting>
+Target[db_replication_lagtime]:extOutput.3&extOutput.3:public at db::30:::
+MaxBytes[db_replication_lagtime]: 400000000
+Title[db_replication_lagtime]: db: replication lag time
+PageTop[db_replication_lagtime]: <H1>db: replication lag time</H1>
+Options[db_replication_lagtime]: gauge,nopercent,growright
+</programlisting>
+
+<para>
+ De son coté, Ismail Yenigul propose une méthode pour surveiller
+ &slony1; en utilisant <application>MRTG</application> sans installer
+ <application>SNMPD</application>.
+</para>
+
+<para>
+ Voici sa configuration MRTG :
+</para>
+
+<programlisting>
+Target[db_replication_lagtime]:`/bin/snmpReplicationLagTime.sh 2`
+MaxBytes[db_replication_lagtime]: 400000000
+Title[db_replication_lagtime]: db: replication lag time
+PageTop[db_replication_lagtime]: <H1>db: replication lag time</H1>
+Options[db_replication_lagtime]: gauge,nopercent,growright
+</programlisting>
+
+<para>
+ Et voici sa version modifiée du script :
+</para>
+
+<programlisting>
+# cat /bin/snmpReplicationLagTime.sh
+#!/bin/bash
+
+output=`/usr/bin/psql -U slony -h 192.168.1.1 -d endersysecm -qAt -c
+"select cast(extract(epoch from st_lag_time) as int8) FROM _mycluster.sl_status WHERE st_received = $1"`
+echo $output
+echo $output
+echo
+echo
+# end of script#
+</programlisting>
+
+<note>
+ <para>
+ MRTG attend quatre lignes en provenance du script. Puisque le script n'en
+ fournit que deux, la sortie doit être prolongée de deux lignes.
+ </para>
+</note>
+
+</sect2>
+
+<sect2 id="testslonystate">
+<title>test_slony_state</title>
+<indexterm><primary>script test_slony_state pour tester l'état de la réplication</primary></indexterm>
+
+<para>
+ Ce script effectue différents analyses sur l'état d'un cluster &slony1;.
+</para>
+
+<para>
+ Vous devez spécifier les arguments tels que la <option>base de
+ données</option>, l'<option>hôte</option>, l'<option>utilisateur</option>,
+ le <option>cluster</option>, le <option>mot de passe</option> et le
+ <option>port</option> afin de se connecter à n'importe quel nœud du
+ cluster. Vous devez également préciser une commande <option>mailprog</option>
+ (qui doit être une commande équivalente à la commande
+ <productname>Unix</productname> <application>mailx</application>) et une
+ destination pour le courrier.
+</para>
+
+<para>
+ Par ailleurs, vous spécifiez les paramètres de connexion aux bases de données
+ via les variables d'environnement utilisées par
+ <application>libpq</application>, <emphasis>par exemple</emphasis> :
+ <envar>PGPORT</envar>, <envar>PGDATABASE</envar>, <envar>PGUSER</envar>,
+ <envar>PGSERVICE</envar> et ainsi de suite.
+</para>
+
+<para>
+ Le script se promène à travers <xref linkend="table.sl-path"/> pour trouver
+ tous les nœuds du cluster et dans les DSNs qui lui permettront de se
+ connecter à chaque nœud.
+</para>
+
+<para>
+ Pour chaque nœud, le script examine l'état des données suivantes :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Vérification de <xref linkend="table.sl-listen"/> à la recherche de
+ problèmes <quote>déterminés analytiquement</quote>. Cela liste les voies
+ de communication qui ne sont pas couvertes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Effectuer un résumé des événements sur le nœud d'origine.
+ </para>
+
+ <para>
+ Si un nœud n'a pas soumis un événement depuis longtemps, il y a
+ certainement un problème.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Vérification de <quote>l'âge</quote> de la table <xref
+ linkend="table.sl-confirm"/>.
+ </para>
+
+ <para>
+ Si un ou plusieurs nœuds du cluster n'ont pas envoyé de rapport
+ récemment, alors cela peut conduire à l'absence de nettoyage dans
+ certaines tables comme <xref linkend="table.sl-log-1"/> et <xref
+ linkend="table.sl-seqlog"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Vérifications des transactions longues.
+ </para>
+
+ <para>
+ Ceci ne fonctionne correctement que si le collecteur de statistique est
+ configuré pour collecter les requêtes, c'est-à-dire l'option
+ <option>stats_command_string = true</option> est présente dans
+ <filename>postgresql.conf</filename>.
+ </para>
+
+ <para>
+ Si des applications buggées conservent des connexions ouvertes, ce script
+ devrait les trouver.
+ </para>
+
+ <para>
+ Si des applications buggées conservent des connexions ouvertes, plusieurs
+ effets négatifs sont à prévoir tels que <link
+ linkend="longtxnsareevil">ceux décrits dans la FAQ</link>.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Ce script fait des diagnostiques basés sur des paramètres définis dans le
+ script ; si vous n'aimez pas les valeurs par défaut, modifiez-les !
+</para>
+
+</sect2>
+
+<sect2 id="search-logs">
+<title><command>search-logs.sh</command></title>
+<indexterm><primary>chercher dans les journaux applicatifs &slony1; avec search-logs.sh</primary></indexterm>
+
+<para>
+ Ce script est construit pour chercher dans les journaux applicatifs &slony1;,
+ à un emplacement donné (<envar>LOGHOME</envar>), en se basant à la fois
+ sur les conventions de nommage utilisées par les systèmes <xref
+ linkend="launchclusters"/> et <xref linkend="slonwatchdog"/> lors du
+ démarrage des processus &lslon;.
+</para>
+
+<para>
+ Si des erreurs sont trouvées, elles sont listées pour chaque fichier et
+ transmises par courriel à un utilisateur spécifié
+ (<envar>LOGRECIPIENT</envar>) ; si aucun courriel n'est spécifié, le
+ résultat est affiché sur la sortie standard.
+</para>
+
+<para>
+ <envar>LOGTIMESTAMP</envar> permet de rechercher à partir de cette (plutôt
+ sur la dernière heure).
+</para>
+
+<para>
+ Un administrateur peut exécuter ce script une fois par heure pour surveiller
+ les problèmes de réplication.
+</para>
+
+</sect2>
+
+<sect2 id="wikigen">
+<title>Produire un rapport de surveillance au format MediaWiki</title>
+<indexterm><primary>générer la documentation Wiki d'un cluster</primary></indexterm>
+
+<para>
+ Le script <filename>mkmediawiki.pl </filename>, situé dans
+ <filename>tools</filename>, peut être utilisé pour générer un rapport de
+ surveillance du cluster compatible avec le populaire logiciel <ulink
+ url="http://www.mediawiki.org/">MediaWiki</ulink>.
+</para>
+
+<para>
+ On pourra utiliser le commande ainsi :
+</para>
+
+<screen>
+~/logtail.en> mvs login -d mywiki.example.info -u "Chris Browne" -p `cat ~/.wikipass` -w wiki/index.php
+Doing login with host: logtail and lang: en
+~/logtail.en> perl $SLONYHOME/tools/mkmediawiki.pl --host localhost --database slonyregress1 --cluster slony_regress1 > Slony_replication.wiki
+~/logtail.en> mvs commit -m "More sophisticated generated Slony-I cluster docs" Slony_replication.wiki
+Doing commit Slony_replication.wiki with host: logtail and lang: en
+</screen>
+
+<para>
+ Notons que <command>mvs</command> est un client Mediawiki écrit en Perl ;
+ sur <ulink url="http://www.debian.org/">Debian GNU/Linux</ulink>, le paquet
+ associé est nommé <application>libwww-mediawiki-client-perl</application> ;
+ d'autres systèmes disposent probablement d'une version packagée sous un nom
+ similaire.
+</para>
+
+</sect2>
+
+</sect1>
Deleted: traduc/tags/slony_1_2_12/slon.xml
===================================================================
--- traduc/trunk/slony/slon.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/slon.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,483 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<refentry id="slon">
- <refmeta>
- <refentrytitle id="app-slon-title"><application>slon</application></refentrytitle>
- <manvolnum>1</manvolnum>
- <refmiscinfo>Application</refmiscinfo>
- </refmeta>
- <refnamediv>
- <refname><application>slon</application></refname>
- <refpurpose>
- Le démon &slony1;
- </refpurpose>
- </refnamediv>
-
- <indexterm zone="slon">
- <primary>slon</primary>
- </indexterm>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>slon</command>
- <arg rep="repeat"><replaceable class="parameter">option</replaceable></arg>
- <arg><replaceable class="parameter">clustername</replaceable></arg>
- <arg><replaceable class="parameter">conninfo</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
-
- <refsect1>
- <title>Description</title>
- <para><application>slon</application> est un démon applicatif qui
- <quote>contrôle</quote> la réplication &slony1;. Une
- instance <application>slon</application> doit être lancée pour
- chaque nœud du cluster &slony1;.</para>
- </refsect1>
-
- <refsect1 id="r1-app-slon-3">
- <title>Options</title>
-
- <variablelist>
- <varlistentry>
- <term><option>-d</option> <replaceable class="parameter">log_level</replaceable></term>
- <listitem>
- <para>
- Le paramètre <envar>log_level</envar> spécifie le niveau de
- messages de débogage que <application>slon</application> doit
- afficher dans son journal d'activité.
- </para>
-
- <para id="nineloglevels">Il y a neuf niveaux de débogage :
- <itemizedlist>
- <listitem><para>Fatal</para></listitem>
- <listitem><para>Error</para></listitem>
- <listitem><para>Warn</para></listitem>
- <listitem><para>Config</para></listitem>
- <listitem><para>Info</para></listitem>
- <listitem><para>Debug1</para></listitem>
- <listitem><para>Debug2</para></listitem>
- <listitem><para>Debug3</para></listitem>
- <listitem><para>Debug4</para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- Les cinq premiers niveaux de débogage (de Fatal à Info) sont
- <emphasis>toujours</emphasis> affichés dans les traces. Dans les
- premières versions de &slony1;, le niveau des traces
- <quote>suggéré</quote> était 2, ce qui affichait tous les messages
- jusqu'au niveau Debug2. Avec &slony1; version 2, il est recommandé
- de positionner <envar>log_level</envar> à 0 ; la plupart des
- informations intéressantes sont produites à des niveaux supérieurs
- à celui-là.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-s</option> <replaceable class="parameter">Intervalle entre
- les vérifications SYNC</replaceable></term>
- <listitem>
- <para>
- Le paramètre <envar>sync_interval</envar>, exprimé en millisecondes,
- indique à quelle fréquence <application>slon</application> doit
- vérifier si un événement <command>SYNC</command> doit être produit.
- La valeur par défaut est 2000 ms. La boucle principale dans
- <function>sync_Thread_main()</function> est endormie pendant des
- intervalles de <envar>sync_interval</envar> millisecondes entre
- chaque itération.
- </para>
-
- <para>
- Un intervalle de vérifications très court garantit que le nœud
- origine soit <quote>très suivi</quote> car il met à jour les abonnés
- plus fréquemment. Si vous avez des séquences répliquées qui sont
- souvent mises à jour <emphasis>sans</emphasis> que certaines tables
- ne soient affectées, cela évite que des opérations qui mettent à
- jour uniquement ces séquences soient effectuées, et ainsi évite la
- génération d'événements de synchronisation.
- </para>
-
- <para>
- Si un nœud n'est pas l'origine d'un ensemble de réplication,
- et donc qu'il ne reçoit aucune mise à jour des données répliquées,
- alors il est un peu inutile de mettre une valeur inférieure à celle
- du paramètre <envar>sync_interval_timeout</envar>.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-t</option><replaceable class="parameter">intervalle maximal
- entre deux SYNC</replaceable></term>
- <listitem>
- <para>
- À la fin de chaque période <envar>sync_interval_timeout</envar>,
- un événement <command>SYNC</command> est produit sur le nœud
- <quote>local</quote> même s'il n'y eu aucune mise à jour des
- données répliquées et qu'aucun <command>SYNC</command> n'a été
- généré.
- </para>
-
- <para>
- Si l'activité de l'application s'arrête, soit parce que
- l'application a été éteinte, soit parce que les utilisateurs humains
- sont rentrés chez eux et arrêtés les mises à jour, alors le démon
- &lslon; continue de tourner et se réveille toutes les
- <envar>sync_interval</envar> millisecondes, et si aucune mise à
- jour ne s'est produite, alors aucun événement <command>SYNC</command>
- n'est généré. Sans ce paramètre <quote>timeout</quote>,
- <emphasis>aucun</emphasis> événement <command>SYNC</command> ne
- pourrait être produit, et cela entraînerait la chute du système de
- réplication.
- </para>
-
- <para>
- Le paramètre <envar>sync_interval_timeout</envar> provoque la
- génération de <command>SYNC</command>, même s'il n'y a pas
- réellement de travail de réplication a faire. Plus la valeur de
- ce paramètre est bas, plus les évènements <command>SYNC</command>
- lorsque l'application n'est pas active. Ceci a deux effets :
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- Le système aura plus de travail.
- </para>
-
- <para>
- (Cependant puisque l'application n'utilise pas la base de
- données et qu'il n'y a pas de données à répliquer, la charge
- de travail supplémentaire sera assez simple à gérer.)
- </para>
- </listitem>
-
- <listitem>
- <para>
- La réplication sera tenue un peu plus <quote>à jour</quote>.
- </para>
-
- <para>
- (Cependant puisqu'il n'y a pas de données à répliquer, être
- plus souvent <quote>mis à jour</quote> est un mirage.)
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- La valeur par défaut est 10000 ms et la valeur maximale est 120000
- ms. Par défaut, vous pouvez prévoir que chaque nœud soit
- <quote>synchronisé</quote> par un <command>SYNC</command> toutes les
- dix secondes.
- </para>
-
- <para>
- Notez que des événements <command>SYNC</command> sont aussi générés
- sur chaque nœud abonné. Cependant, puisqu'ils ne contiennent
- pas de données à répliquer par les autres nœuds, les évènements
- <command>SYNC</command> des nœuds abonnés ne sont pas
- terriblement intéressants.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-g</option> <replaceable class="parameter">taille du groupe</replaceable></term>
- <listitem>
- <para>
- L'option <envar>sync_group_maxsize</envar> contrôle la taille
- maximale d'un groupe <command>SYNC</command>. La valeur par défaut
- est 6. Ainsi, si un nœud particulier a 200 événements
- <command>SYNC</command> de retard, il essaiera de les regrouper
- par groupes dont la taille maximale sera
- <envar>sync_group_maxsize</envar>. Ceci doit permettre de réduire
- le temps de lantence au démarrage (NdT : « overhead »)
- en réduisant le nombre de transactions à <quote>valider</quote>.
- </para>
-
- <para>
- La valeur par défaut, 6, est probablement adéquate pour les petits
- systèmes qui ne peuvent allouer que des quantités limitées de
- mémoire à <application>slon</application>. Si vous avez beaucoup de
- mémoire, il est raisonnable d'augmenter cette valeur car cela
- augmentera la quantité de travail réalisée à chaque transaction, et
- cela permettra à un nœud abonné de rattraper plus vite son
- retard.
- </para>
-
- <para>
- Les processus Slon sont souvent très petits ; même en cas
- de valeurs très fortes pour cette option,
- <application>slon</application> devrait simplement grossir de
- quelques Mo.
- </para>
-
- <para>
- Le gros avantage d'augmenter ce paramètre est que cela divise
- le nombre de transactions <command>COMMIT</command> ; passer
- de 1 à 2 aura probablement un impact considérable, mais le bénéfice
- se réduit progressivement lorsque la taille des groupes est
- suffisamment large. Il n'y aura probablement pas de différence
- notable entre 80 et 90. Rendu à ce niveau, l'augmentation de cette
- valeur dépend du fait que les grands ensembles de <command>SYNC</command>
- perturbent les curseurs de <envar>LOG</envar> en consommant de plus
- en plus de mémoire et nécessitant plus d'efforts lors des tris.
- </para>
-
- <para>
- Dans &slony1; version 1.0, <application>slon</application> essaie
- toujours de regrouper un maximum de <command>SYNC</command> ensemble,
- ce qui <emphasis>n'est pas</emphasis> idéal si la réplication a été
- déstabilisée par de grosses mises à jour (<emphasis>par
- exemple</emphasis>, une transaction unique qui met à jour des
- centaines de milliers de lignes) ou lorsque les
- <command>SYNC</command> ont été interrompus sur un nœud origine,
- ce qui fait que les suivants sont volumineux. Vous rencontrerez ce
- problème : en regroupant des <command>SYNC</command> très
- larges, le processus <application>slon</application> peut échouer.
- Au redémarrage, il essaie à nouveau de traiter ce large ensemble
- de <command>SYNC</command> et il retombe sur le même problème
- encore et encore jusqu'à ce qu'un administrateur interrompe tout
- cela et change la valeur de l'option <option>-g</option> pour
- sortir de cette situation d'<quote>inter-blocage</quote>.
- </para>
-
- <para>
- Au contraire, avec &slony1; 1.0, le démon
- <application>slon</application> s'adapte en augmentant
- <quote>progressivement</quote> le nombre de <command>SYNC</command>
- par groupe, de 1 jusqu'à la valeur maximale. Ainsi, si quelques
- <command>SYNC</command> posent problème, le démon
- <application>slon</application> pourra (s'il est surveillé par
- un processus chien de garde) traiter un par un ces évènements
- <command>SYNC</command> problématiques, et ainsi éviter
- l'intervention d'un administrateur.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-o</option> <replaceable class="parameter">temps de
- synchronisation souhaité</replaceable></term>
- <listitem>
- <para>
- La période <quote>maximale</quote> pour un groupe de
- <command>SYNC</command>.
- </para>
-
- <para>
- Si la réplication est en retard, le démon slon va progressivement
- augmenter le nombre de <command>SYNC</command> groupés ensemble,
- dans le but de ne pas dépasser le temps spécifié par
- <envar>desired_sync_time</envar> (pour cela, Slon se base sur le
- temps pris par le <emphasis>dernier</emphasis> groupe de
- <command>SYNC</command>).
- </para>
-
- <para>
- La valeur par défaut est 60000ms, c'est-à-dire une minute.
- </para>
-
- <para>
- Ainsi, vous pouvez prévoir (en tout cas espérer !) que vous
- aurez un <command>COMMIT</command> environ toutes les minutes.
- </para>
-
- <para>
- Cela n'est pas <emphasis>complètement</emphasis> prévisible car il
- est possible de demander une <emphasis>très grosse mise à
- jour</emphasis> qui fera <quote>exploser</quote> la taille du
- <command>SYNC</command>. Dans ce cas-là, l'heuristique sera rétablie
- pour le <emphasis>prochain</emphasis> groupe.
- </para>
-
- <para>
- L'effet final est d'améliorer la façon dont
- <productname>Slony-I</productname> gère les variations du trafic.
- En commençant avec un événement <command>SYNC</command>, puis
- en augmentant progressivement, même si certaines variations seront
- assez grandes pour provoquer un crash du processus
- <productname>PostgreSQL</productname>, <productname>Slony-I</productname>
- redémarrera en traitant un seul <command>SYNC</command> à la fois,
- afin que poursuivre le processus de réplication autant que possible.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-c</option> <replaceable class="parameter">cycles de nettoyage</replaceable></term>
- <listitem>
- <para>
- La valeur <envar>vac_frequency</envar> indique la fréquence des
- opérations <command>VACUUM</command> lors des cycles de nettoyage.
- </para>
-
- <para>
- Positionnez cette valeur à zéro pour désactiver les nettoyages
- initiés par <application>slon</application>. Si vous utilisez un
- mécanisme tel que <application>pg_autovacuum</application> pour
- lancer les VACUUM, vous n'aurez probablement pas besoin que slon
- initie des VACUUM de lui-même. Sinon, il existe des tables
- utilisées par <productname>Slony-I</productname> qui collectent
- <emphasis>beaucoup</emphasis> de lignes mortes et qui doivent
- être nettoyées fréquemment, en particulier &pglistener;.
- </para>
-
- <para>
- À partir de &slony1; version 1.1, cela change un peu ; le
- processus de nettoyage cherche, d'itération en itération,
- l'identifiant de la plus ancienne transaction encore active dans
- le système. Si l'identifiant ne change pas entre deux itérations,
- alors il existe une vieille transaction en activité, et donc un
- <command>VACUUM</command> n'apportera rien de bon. À la place, le
- processus de nettoyage déclenche simplement une opération
- <command>ANALYZE</command> sur ces tables afin de mettre à jours
- les statistiques dans <envar>pg_statistics</envar>.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-p</option> <replaceable class="parameter">fichier du PID</replaceable></term>
- <listitem>
- <para>
- La variable <envar>pid_file</envar> contient le nom du fichier dans
- lequel le PID (identifiant du processus) du démon
- <application>slon</application> est stocké.
- </para>
-
- <para>
- Cela simplifie la création de scripts de surveillance des processus
- <application>slon</application> qui s'exécutent sur un hôte.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-f</option> <replaceable class="parameter">fichier de configuration</replaceable></term>
- <listitem>
- <para>
- Fichier qui contient la configuration <application>slon</application>.
- </para>
-
- <para>
- La configuration est détaillée plus loin dans le chapitre <link
- linkend="runtime-config">Configuration de Slon</link>. Si vous avez
- défini un ensemble complexe de paramètre ou si vous ne voulez pas
- que les paramètres soient visibles dans les variables d'environnement
- (notamment les mots de passe), il est plus pratique de placer une
- partie, voire l'ensemble des paramètres dans un fichier de
- configuration. Vous pouvez également placer les paramètres communs à
- tous les processus slon dans un fichier de configuration partagé et
- définir en ligne de commande d'autres paramètres que les informations
- de connexions. Vous pouvez aussi créer un fichier de configuration
- pour chaque nœud.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-a</option> <replaceable class="parameter">répertoire des archives</replaceable></term>
- <listitem>
- <para>
- L'option <envar>archive_dir</envar> indique le dossier dans lequel
- on place la séquence de fichiers archives contenant les événements
- <command>SYNC</command> utilisés en mode &logshiplink;.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-x</option> <replaceable class="parameter">commande à
- appliquer pour l'archivage des journaux</replaceable></term>
- <listitem>
- <para>
- Le paramètre <envar>command_on_logarchive</envar> indique la commande
- qui doit être exécutée à chaque fois qu'un fichier SYNC est
- correctement généré.
- </para>
-
- <para>
- Voir le chapitre <xref linkend="slon-config-command-on-logarchive"/>
- pour plus de détails.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-q</option> <replaceable class="parameter">quitter en
- fonction d'un fournisseur</replaceable></term>
- <listitem>
- <para>
- L'option <envar>quit_sync_provider</envar> indique quel processus
- fournisseur doit être surveilleé afin d'arrêter la réplication
- après un événement donné. Ceci doit être utilisé conjointement avec
- l'option <option>-r</option> ci-dessous...
- </para>
-
- <para>
- Cela permet de stopper la réplication sur un processus
- <application>slon</application> après un certain point.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-r</option> <replaceable class="parameter">quitte après
- un numéro d'événement</replaceable></term>
- <listitem>
- <para>
- Le paramètre <envar>quit_sync_finalsync</envar> indique le numéro
- de l'événement après lequel un processus de réplication doit se
- terminer. Ceci doit être utilisé conjointement avec l'option
- <option>-q</option> ci-dessus...</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-l</option> <replaceable class="parameter"> interval de retard</replaceable></term>
- <listitem>
- <para>
- L'option <envar>lag_interval</envar> spécifie une valeur temporelle
- (en anglais) telle que <command>3 minutes</command>, <command>4
- hours</command> ou <command>2 days</command> qui indique le temps
- de retard que doit avoir un nœud par rapport à son fournisseur.
- Cela implique que les événements seront ignorés tant que leur âge
- sera inférieur à cet intervalle.
- </para>
-
- <warning>
- <para>
- Il y a un effet secondaire à ce retard ; Les événements qui
- demandent que tous les nœuds se synchronisent, notamment
- ceux qui sont produits lors d'une opération <xref
- linkend="stmtfailover"/> et d'un <xref linkend="stmtmoveset"/>,
- devront attendre pendant cet interval de temps.
- </para>
-
- <para>
- C'est un comportement qui n'est pas idéal dans le cas d'une bascule
- après une panne, ou lorsque l'on veut exécuter des scripts DDL
- (<xref linkend="stmtddlscript"/> ).
- </para>
- </warning>
- </listitem>
- </varlistentry>
- </variablelist>
- </refsect1>
-
- <refsect1>
- <title>Valeur de retour</title>
-
- <para>
- <application>slon</application> renvoie 0 dans le shell s'il s'est terminé
- normalement. En cas d'erreur fatale, il exécute la fonction
- <function>exit(-1)</function> (qui envoie en général une valeur de retour
- de 127 ou 255, suivant votre système d'exploitation).
- </para>
- </refsect1>
-</refentry>
Copied: traduc/tags/slony_1_2_12/slon.xml (from rev 1244, traduc/trunk/slony/slon.xml)
===================================================================
--- traduc/tags/slony_1_2_12/slon.xml (rev 0)
+++ traduc/tags/slony_1_2_12/slon.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,480 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<refentry id="slon">
+ <refmeta>
+ <refentrytitle id="app-slon-title"><application>slon</application></refentrytitle>
+ <manvolnum>1</manvolnum>
+ <refmiscinfo>Application</refmiscinfo>
+ </refmeta>
+ <refnamediv>
+ <refname><application>slon</application></refname>
+ <refpurpose>
+ Le démon &slony1;
+ </refpurpose>
+ </refnamediv>
+
+ <indexterm zone="slon">
+ <primary>slon</primary>
+ </indexterm>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>slon</command>
+ <arg rep="repeat"><replaceable class="parameter">option</replaceable></arg>
+ <arg><replaceable class="parameter">clustername</replaceable></arg>
+ <arg><replaceable class="parameter">conninfo</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+
+ <refsect1>
+ <title>Description</title>
+ <para><application>slon</application> est un démon applicatif qui
+ <quote>contrôle</quote> la réplication &slony1;. Une
+ instance <application>slon</application> doit être lancée pour
+ chaque nœud du cluster &slony1;.</para>
+ </refsect1>
+
+ <refsect1 id="r1-app-slon-3">
+ <title>Options</title>
+
+ <variablelist>
+ <varlistentry>
+ <term><option>-d</option> <replaceable class="parameter">log_level</replaceable></term>
+ <listitem>
+ <para>
+ Le paramètre <envar>log_level</envar> spécifie le niveau de
+ messages de débogage que <application>slon</application> doit
+ afficher dans son journal d'activité.
+ </para>
+
+ <para id="nineloglevels">Il y a neuf niveaux de débogage :
+ <itemizedlist>
+ <listitem><para>Fatal</para></listitem>
+ <listitem><para>Error</para></listitem>
+ <listitem><para>Warn</para></listitem>
+ <listitem><para>Config</para></listitem>
+ <listitem><para>Info</para></listitem>
+ <listitem><para>Debug1</para></listitem>
+ <listitem><para>Debug2</para></listitem>
+ <listitem><para>Debug3</para></listitem>
+ <listitem><para>Debug4</para></listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ Les cinq premiers niveaux de débogage (de Fatal à Info) sont
+ <emphasis>toujours</emphasis> affichés dans les traces. Si
+ <envar>log_level</envar> est configuré à 2 (un choix routinier et,
+ généralement, préférable), alors les messages de niveaux de
+ débogage 1 et 2 seront aussi envoyés.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-s</option> <replaceable class="parameter">Intervalle entre
+ les vérifications SYNC</replaceable></term>
+ <listitem>
+ <para>
+ Le paramètre <envar>sync_interval</envar>, exprimé en millisecondes,
+ indique à quelle fréquence <application>slon</application> doit
+ vérifier si un événement <command>SYNC</command> doit être produit.
+ La valeur par défaut est 2000 ms. La boucle principale dans
+ <function>sync_Thread_main()</function> est endormie pendant des
+ intervalles de <envar>sync_interval</envar> millisecondes entre
+ chaque itération.
+ </para>
+
+ <para>
+ Un intervalle de vérifications très court garantit que le nœud
+ origine soit <quote>très suivi</quote> car il met à jour les abonnés
+ plus fréquemment. Si vous avez des séquences répliquées qui sont
+ souvent mises à jour <emphasis>sans</emphasis> que certaines tables
+ ne soient affectées, cela évite que des opérations qui mettent à
+ jour uniquement ces séquences soient effectuées, et ainsi évite la
+ génération d'événements de synchronisation.
+ </para>
+
+ <para>
+ Si un nœud n'est pas l'origine d'un ensemble de réplication,
+ et donc qu'il ne reçoit aucune mise à jour des données répliquées,
+ alors il est un peu inutile de mettre une valeur inférieure à celle
+ du paramètre <envar>sync_interval_timeout</envar>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-t</option><replaceable class="parameter">intervalle maximal
+ entre deux SYNC</replaceable></term>
+ <listitem>
+ <para>
+ À la fin de chaque période <envar>sync_interval_timeout</envar>,
+ un événement <command>SYNC</command> est produit sur le nœud
+ <quote>local</quote> même s'il n'y eu aucune mise à jour des
+ données répliquées et qu'aucun <command>SYNC</command> n'a été
+ généré.
+ </para>
+
+ <para>
+ Si l'activité de l'application s'arrête, soit parce que
+ l'application a été éteinte, soit parce que les utilisateurs humains
+ sont rentrés chez eux et arrêtés les mises à jour, alors le démon
+ &lslon; continue de tourner et se réveille toutes les
+ <envar>sync_interval</envar> millisecondes, et si aucune mise à
+ jour ne s'est produite, alors aucun événement <command>SYNC</command>
+ n'est généré. Sans ce paramètre <quote>timeout</quote>,
+ <emphasis>aucun</emphasis> événement <command>SYNC</command> ne
+ pourrait être produit, et cela entraînerait la chute du système de
+ réplication.
+ </para>
+
+ <para>
+ Le paramètre <envar>sync_interval_timeout</envar> provoque la
+ génération de <command>SYNC</command>, même s'il n'y a pas
+ réellement de travail de réplication a faire. Plus la valeur de
+ ce paramètre est bas, plus les évènements <command>SYNC</command>
+ lorsque l'application n'est pas active. Ceci a deux effets :
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Le système aura plus de travail.
+ </para>
+
+ <para>
+ (Cependant puisque l'application n'utilise pas la base de
+ données et qu'il n'y a pas de données à répliquer, la charge
+ de travail supplémentaire sera assez simple à gérer.)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ La réplication sera tenue un peu plus <quote>à jour</quote>.
+ </para>
+
+ <para>
+ (Cependant puisqu'il n'y a pas de données à répliquer, être
+ plus souvent <quote>mis à jour</quote> est un mirage.)
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ La valeur par défaut est 10000 ms et la valeur maximale est 120000
+ ms. Par défaut, vous pouvez prévoir que chaque nœud soit
+ <quote>synchronisé</quote> par un <command>SYNC</command> toutes les
+ dix secondes.
+ </para>
+
+ <para>
+ Notez que des événements <command>SYNC</command> sont aussi générés
+ sur chaque nœud abonné. Cependant, puisqu'ils ne contiennent
+ pas de données à répliquer par les autres nœuds, les évènements
+ <command>SYNC</command> des nœuds abonnés ne sont pas
+ terriblement intéressants.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-g</option> <replaceable class="parameter">taille du groupe</replaceable></term>
+ <listitem>
+ <para>
+ L'option <envar>sync_group_maxsize</envar> contrôle la taille
+ maximale d'un groupe <command>SYNC</command>. La valeur par défaut
+ est 6. Ainsi, si un nœud particulier a 200 événements
+ <command>SYNC</command> de retard, il essaiera de les regrouper
+ par groupes dont la taille maximale sera
+ <envar>sync_group_maxsize</envar>. Ceci doit permettre de réduire
+ le temps de lantence au démarrage (NdT : « overhead »)
+ en réduisant le nombre de transactions à <quote>valider</quote>.
+ </para>
+
+ <para>
+ La valeur par défaut, 6, est probablement adéquate pour les petits
+ systèmes qui ne peuvent allouer que des quantités limitées de
+ mémoire à <application>slon</application>. Si vous avez beaucoup de
+ mémoire, il est raisonnable d'augmenter cette valeur car cela
+ augmentera la quantité de travail réalisée à chaque transaction, et
+ cela permettra à un nœud abonné de rattraper plus vite son
+ retard.
+ </para>
+
+ <para>
+ Les processus Slon sont souvent très petits ; même en cas
+ de valeurs très fortes pour cette option,
+ <application>slon</application> devrait simplement grossir de
+ quelques Mo.
+ </para>
+
+ <para>
+ Le gros avantage d'augmenter ce paramètre est que cela divise
+ le nombre de transactions <command>COMMIT</command> ; passer
+ de 1 à 2 aura probablement un impact considérable, mais le bénéfice
+ se réduit progressivement lorsque la taille des groupes est
+ suffisamment large. Il n'y aura probablement pas de différence
+ notable entre 80 et 90. Rendu à ce niveau, l'augmentation de cette
+ valeur dépend du fait que les grands ensembles de <command>SYNC</command>
+ perturbent les curseurs de <envar>LOG</envar> en consommant de plus
+ en plus de mémoire et nécessitant plus d'efforts lors des tris.
+ </para>
+
+ <para>
+ Dans &slony1; version 1.0, <application>slon</application> essaie
+ toujours de regrouper un maximum de <command>SYNC</command> ensemble,
+ ce qui <emphasis>n'est pas</emphasis> idéal si la réplication a été
+ déstabilisée par de grosses mises à jour (<emphasis>par
+ exemple</emphasis>, une transaction unique qui met à jour des
+ centaines de milliers de lignes) ou lorsque les
+ <command>SYNC</command> ont été interrompus sur un nœud origine,
+ ce qui fait que les suivants sont volumineux. Vous rencontrerez ce
+ problème : en regroupant des <command>SYNC</command> très
+ larges, le processus <application>slon</application> peut échouer.
+ Au redémarrage, il essaie à nouveau de traiter ce large ensemble
+ de <command>SYNC</command> et il retombe sur le même problème
+ encore et encore jusqu'à ce qu'un administrateur interrompe tout
+ cela et change la valeur de l'option <option>-g</option> pour
+ sortir de cette situation d'<quote>inter-blocage</quote>.
+ </para>
+
+ <para>
+ Au contraire, avec &slony1; 1.0, le démon
+ <application>slon</application> s'adapte en augmentant
+ <quote>progressivement</quote> le nombre de <command>SYNC</command>
+ par groupe, de 1 jusqu'à la valeur maximale. Ainsi, si quelques
+ <command>SYNC</command> posent problème, le démon
+ <application>slon</application> pourra (s'il est surveillé par
+ un processus chien de garde) traiter un par un ces évènements
+ <command>SYNC</command> problématiques, et ainsi éviter
+ l'intervention d'un administrateur.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-o</option> <replaceable class="parameter">temps de
+ synchronisation souhaité</replaceable></term>
+ <listitem>
+ <para>
+ La période <quote>maximale</quote> pour un groupe de
+ <command>SYNC</command>.
+ </para>
+
+ <para>
+ Si la réplication est en retard, le démon slon va progressivement
+ augmenter le nombre de <command>SYNC</command> groupés ensemble,
+ dans le but de ne pas dépasser le temps spécifié par
+ <envar>desired_sync_time</envar> (pour cela, Slon se base sur le
+ temps pris par le <emphasis>dernier</emphasis> groupe de
+ <command>SYNC</command>).
+ </para>
+
+ <para>
+ La valeur par défaut est 60000ms, c'est-à-dire une minute.
+ </para>
+
+ <para>
+ Ainsi, vous pouvez prévoir (en tout cas espérer !) que vous
+ aurez un <command>COMMIT</command> environ toutes les minutes.
+ </para>
+
+ <para>
+ Cela n'est pas <emphasis>complètement</emphasis> prévisible car il
+ est possible de demander une <emphasis>très grosse mise à
+ jour</emphasis> qui fera <quote>exploser</quote> la taille du
+ <command>SYNC</command>. Dans ce cas-là, l'heuristique sera rétablie
+ pour le <emphasis>prochain</emphasis> groupe.
+ </para>
+
+ <para>
+ L'effet final est d'améliorer la façon dont
+ <productname>Slony-I</productname> gère les variations du trafic.
+ En commençant avec un événement <command>SYNC</command>, puis
+ en augmentant progressivement, même si certaines variations seront
+ assez grandes pour provoquer un crash du processus
+ <productname>PostgreSQL</productname>, <productname>Slony-I</productname>
+ redémarrera en traitant un seul <command>SYNC</command> à la fois,
+ afin que poursuivre le processus de réplication autant que possible.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-c</option> <replaceable class="parameter">cycles de nettoyage</replaceable></term>
+ <listitem>
+ <para>
+ La valeur <envar>vac_frequency</envar> indique la fréquence des
+ opérations <command>VACUUM</command> lors des cycles de nettoyage.
+ </para>
+
+ <para>
+ Positionnez cette valeur à zéro pour désactiver les nettoyages
+ initiés par <application>slon</application>. Si vous utilisez un
+ mécanisme tel que <application>pg_autovacuum</application> pour
+ lancer les VACUUM, vous n'aurez probablement pas besoin que slon
+ initie des VACUUM de lui-même. Sinon, il existe des tables
+ utilisées par <productname>Slony-I</productname> qui collectent
+ <emphasis>beaucoup</emphasis> de lignes mortes et qui doivent
+ être nettoyées fréquemment, en particulier &pglistener;.
+ </para>
+
+ <para>
+ À partir de &slony1; version 1.1, cela change un peu ; le
+ processus de nettoyage cherche, d'itération en itération,
+ l'identifiant de la plus ancienne transaction encore active dans
+ le système. Si l'identifiant ne change pas entre deux itérations,
+ alors il existe une vieille transaction en activité, et donc un
+ <command>VACUUM</command> n'apportera rien de bon. À la place, le
+ processus de nettoyage déclenche simplement une opération
+ <command>ANALYZE</command> sur ces tables afin de mettre à jours
+ les statistiques dans <envar>pg_statistics</envar>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-p</option> <replaceable class="parameter">fichier du PID</replaceable></term>
+ <listitem>
+ <para>
+ La variable <envar>pid_file</envar> contient le nom du fichier dans
+ lequel le PID (identifiant du processus) du démon
+ <application>slon</application> est stocké.
+ </para>
+
+ <para>
+ Cela simplifie la création de scripts de surveillance des processus
+ <application>slon</application> qui s'exécutent sur un hôte.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-f</option> <replaceable class="parameter">fichier de configuration</replaceable></term>
+ <listitem>
+ <para>
+ Fichier qui contient la configuration <application>slon</application>.
+ </para>
+
+ <para>
+ La configuration est détaillée plus loin dans le chapitre <link
+ linkend="runtime-config">Configuration de Slon</link>. Si vous avez
+ défini un ensemble complexe de paramètre ou si vous ne voulez pas
+ que les paramètres soient visibles dans les variables d'environnement
+ (notamment les mots de passe), il est plus pratique de placer une
+ partie, voire l'ensemble des paramètres dans un fichier de
+ configuration. Vous pouvez également placer les paramètres communs à
+ tous les processus slon dans un fichier de configuration partagé et
+ définir en ligne de commande d'autres paramètres que les informations
+ de connexions. Vous pouvez aussi créer un fichier de configuration
+ pour chaque nœud.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-a</option> <replaceable class="parameter">répertoire des archives</replaceable></term>
+ <listitem>
+ <para>
+ L'option <envar>archive_dir</envar> indique le dossier dans lequel
+ on place la séquence de fichiers archives contenant les événements
+ <command>SYNC</command> utilisés en mode &logshiplink;.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-x</option> <replaceable class="parameter">commande à
+ appliquer pour l'archivage des journaux</replaceable></term>
+ <listitem>
+ <para>
+ Le paramètre <envar>command_on_logarchive</envar> indique la commande
+ qui doit être exécutée à chaque fois qu'un fichier SYNC est
+ correctement généré.
+ </para>
+
+ <para>
+ Voir le chapitre <xref linkend="slon-config-command-on-logarchive"/>
+ pour plus de détails.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-q</option> <replaceable class="parameter">quitter en
+ fonction d'un fournisseur</replaceable></term>
+ <listitem>
+ <para>
+ L'option <envar>quit_sync_provider</envar> indique quel processus
+ fournisseur doit être surveilleé afin d'arrêter la réplication
+ après un événement donné. Ceci doit être utilisé conjointement avec
+ l'option <option>-r</option> ci-dessous...
+ </para>
+
+ <para>
+ Cela permet de stopper la réplication sur un processus
+ <application>slon</application> après un certain point.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-r</option> <replaceable class="parameter">quitte après
+ un numéro d'événement</replaceable></term>
+ <listitem>
+ <para>
+ Le paramètre <envar>quit_sync_finalsync</envar> indique le numéro
+ de l'événement après lequel un processus de réplication doit se
+ terminer. Ceci doit être utilisé conjointement avec l'option
+ <option>-q</option> ci-dessus...</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-l</option> <replaceable class="parameter"> interval de retard</replaceable></term>
+ <listitem>
+ <para>
+ L'option <envar>lag_interval</envar> spécifie une valeur temporelle
+ (en anglais) telle que <command>3 minutes</command>, <command>4
+ hours</command> ou <command>2 days</command> qui indique le temps
+ de retard que doit avoir un nœud par rapport à son fournisseur.
+ Cela implique que les événements seront ignorés tant que leur âge
+ sera inférieur à cet intervalle.
+ </para>
+
+ <warning>
+ <para>
+ Il y a un effet secondaire à ce retard ; Les événements qui
+ demandent que tous les nœuds se synchronisent, notamment
+ ceux qui sont produits lors d'une opération <xref
+ linkend="stmtfailover"/> et d'un <xref linkend="stmtmoveset"/>,
+ devront attendre pendant cet interval de temps.
+ </para>
+
+ <para>
+ C'est un comportement qui n'est pas idéal dans le cas d'une bascule
+ après une panne, ou lorsque l'on veut exécuter des scripts DDL
+ (<xref linkend="stmtddlscript"/> ).
+ </para>
+ </warning>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </refsect1>
+
+ <refsect1>
+ <title>Valeur de retour</title>
+
+ <para>
+ <application>slon</application> renvoie 0 dans le shell s'il s'est terminé
+ normalement. En cas d'erreur fatale, il exécute la fonction
+ <function>exit(-1)</function> (qui envoie en général une valeur de retour
+ de 127 ou 255, suivant votre système d'exploitation).
+ </para>
+ </refsect1>
+</refentry>
Deleted: traduc/tags/slony_1_2_12/slonconf.xml
===================================================================
--- traduc/trunk/slony/slonconf.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/slonconf.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,525 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<article id="runtime-config">
- <title>Configuration</title>
- <indexterm>
- <primary>configuration</primary>
- <secondary>du démon slon</secondary>
- </indexterm>
-
- <para>
- Il existe plusieurs paramètres de configuration qui affectent le comportement
- du système de réplication. Dans cette section, nous allons décrire
- comment définir les paramètres de configuration du démon
- <application>slon</application> ; La sous-section qui suit détaille
- chaque paramètre :
- </para>
-
- <para>
- Tous les noms de paramètres sont sensibles à la casse des lettres.
- Chaque paramètre se voir assigner un type : booléen,
- entier, flottant ou chaîne de caractères. Les valeurs booléennes
- peuvent être <literal>ON</literal>, <literal>OFF</literal>,
- <literal>FALSE</literal>, <literal>YES</literal>, <literal>NO</literal>,
- <literal>1</literal>, <literal>0</literal> (toutes en majuscule) ou
- n'importe quel préfixe non ambigü de ces valeurs.
- </para>
-
- <para>
- On spécifie un paramètre par ligne. Le signe égal entre le nom
- et la valeur est optionnel. Les espaces ne sont pas
- significatifs et les lignes vides sont ignorées.
- Le caractère dièse (<literal>#</literal>) permet de placer
- un commentaire n'importe où. Les valeurs des paramètres qui ne
- sont pas des identifiant ou des nombres doivent être encadrées
- par des guillemets simples.
- </para>
-
- <para>
- Certaines options peuvent être définies en ligne de commande,
- ces options surchargent les paramètres identiques qui se trouvent
- dans le fichier de configuration.
- </para>
-
-
-<sect1 id="slon-config-logging">
- <title>Traces</title>
- <variablelist>
- <varlistentry id="slon-config-logging-syslog" xreflabel="slon_conf_syslog">
- <term>
- <varname>syslog</varname> (<type>entier</type>)
- <indexterm>
- <primary>paramètre de configuration de <varname>syslog</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Active les traces avec syslog. Si le paramètre vaut 1, les messages vont
- à la fois vers syslog et la sortie standard. La valeur 2 envoie les traces
- uniquement à syslog. Toutefois, certains messages seront toujours envoyés
- sur la sortie standard ou sur la sortie des erreurs. Par défaut, ce paramètre
- est à 0, ce qui signifie que syslog est désactivé.</para>
- </listitem>
- </varlistentry>
- <varlistentry id="slon-config-logging-syslog-facility" xreflabel="slon_conf_syslog_facility">
- <term>
- <varname>syslog_facility</varname> (<type>chaîne</type>)
- <indexterm>
- <primary>paramètre de configuration de <varname>syslog_facility</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Positionne la <quote>facility</quote> que syslog devra utiliser.
- Les valeurs valides sont LOCAL0, LOCAL1, LOCAL2,
- LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. La valeur par défaut est
- LOCAL0.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-logging-syslog-ident" xreflabel="slon_conf_syslog_ident">
- <term>
- <varname>syslog_ident</varname> (<type>chaîne</type>)
- <indexterm>
- <primary>Paramètre de configuration de <varname>syslog_ident</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Définit le nom du programme utilisé pour identifier les messages slon
- dans syslog. La valeur par défaut est slon.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-logging-log-level" xreflabel="lon_conf_log_level">
- <term>
- <varname>log_level</varname> (<type>entier</type>)
- <indexterm>
- <primary>Paramètre de configuration du <varname>log_level</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Niveau de traces de débogage (plus la valeur est haute, plus les
- messages sont verbeux).
- Valeurs possibles : de 0 à 4. Valeur par défaut : 0.</para>
-
- <para>Il y a <link linkend="nineloglevels">neuf niveaux de messages
- de trace</link> ; en utilisant cette option, une partie ou l'ensemble
- des niveaux <quote>debug</quote> peut être désactivé.
- Avec &slony1; version 2, beaucoup de niveaux de message ont
- été révisé afin que des <quote>informations intéressantes</quote>
- apparaissent à partir des niveaux CONFIG/INFO, et qu'il soit possible
- de fonctionner au niveau 0, en ignorant tous les messages
- <quote>DEBUG</quote> et continuer à recevoir des informations
- utiles dans les journaux applicatifs.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-logging-log-pid" xreflabel="slon_conf_log_pid">
- <term>
- <varname>log_pid</varname> (<type>booléen</type>)
- <indexterm>
- <primary>paramètre de configuration du <varname>log_pid</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Détermine si le PID du processus père slon
- doit apparaître dans chaque ligne du journal applicatif.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-logging-log-timestamp" xreflabel="slon_conf_log_timestamp">
- <term>
- <varname>log_timestamp</varname> (<type>booléen</type>)
- <indexterm>
- <primary>paramètre de configuration de <varname>log_timestamp</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Détermine si l'horodatage de chaque événement doit
- apparaître dans chaque ligne du journal applicatif.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-logging-log-timestamp-format" xreflabel="slon_conf_log_timestamp_format">
- <term>
- <varname>log_timestamp_format</varname> (<type>chaîne</type>)
- <indexterm>
- <primary>paramètre de configuration du <varname>log_timestamp_format</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Une chaîne au format conforme avec <function>strftime()</function>
- qui sera utilisé si <envar>log_timestamp</envar> est activé.
- La valeur par défaut est <quote>%Y-%m-%d %H:%M:%S %Z</quote></para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-logging-pid-file" xreflabel="slon_conf_log_pid_file">
- <term>
- <varname>pid_file</varname> (<type>chaîne</type>)
- <indexterm>
- <primary>paramètre de configuration du <varname>pid_file</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>L'emplacement et le nom du fichier où vous souhaitez
- stocker le PID du processus slon. La valeur par défaut n'est
- pas définie, ce qui implique qu'aucun fichier n'est écrit.</para>
- </listitem>
- </varlistentry>
- </variablelist>
-</sect1>
-
-<sect1 id="slon-config-connection">
- <title>Paramètres de connexion</title>
- <variablelist>
- <varlistentry id="slon-config-connection-cluster-name" xreflabel="slon_conf_cluster_name">
- <term>
- <varname>cluster_name</varname> (<type>chaîne</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>cluster_name</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>
- Définit le nom du cluster que l'instance de
- <application>slon</application> doit gérer.
- Par défaut, cette valeur est obtenue en ligne de commande.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-connection-conn-info" xreflabel="slon_conf_conn_info">
- <term><varname>conn_info</varname> (<type>chaîne</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>conn_info</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>
- Définit les informations de connexion pour <application>slon</application>.
- Par défaut, cette valeur est obtenue en ligne de commande.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-sql-on-connection" xreflabel="slon_conf_sql_on_connection">
- <term><varname>sql_on_connection</varname> (<type>chaîne</type>)
- <indexterm>
- <primary>paramètre de configuration de <varname>sql_on_connection</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>
- Exécute cette requête SQL sur chaque nœud lorsque
- <application>slon</application> s'y connecte. Utile pour
- définir un niveau de trace, ou pour configurer les
- paramètres du planificateur ou de la mémoire.
- Vous pouvez spécifier de multiples requêtes en les
- séparant par un point-virgule.
- </para>
- </listitem>
- </varlistentry>
-
- </variablelist>
-</sect1>
-<sect1 id="slon-archive-logging">
- <title>Options d'archivage</title>
- <variablelist>
- <varlistentry id="slon-config-archive-dir" xreflabel="slon_conf_archive_dir">
- <term><varname>archive_dir</varname> (<type>text</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>archive_dir</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Ceci indique dans quel répertoire les fichiers d'archivages des SYNC doivent
- être stockés.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-command-on-logarchive" xreflabel="slon_conf_command_on_log_archive">
- <term><varname>command_on_logarchive</varname> (<type>texte</type>)
- <indexterm>
- <primary>paramètre de configuration de <varname>command_on_logarchive</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Ce paramètre définit une commande Unix qui sera exécutée à
- chaque fois qu'un fichier d'archive est produit.
- </para>
-
- <para>Un paramètre est passé à cette commande : le chemin absolu
- du fichier d'archive. Ainsi, si on imagine la configuration suivante :
- </para>
-
- <para>
- <command>command_on_logarchive = <filename>/usr/local/bin/logstuff</filename></command>
- </para>
- <para>
- <command>archive_dir = <filename>/var/log/slony1/archivelogs/payroll</filename></command>
- </para>
-
- <para>Un fichier de d'archive sera nommé de cette façon :
- <filename>/var/log/slony1/archivelogs/payroll/slony1_log_1_00000000000000000036.sql</filename></para>
-
- <para>La commande exécutée après que le SYNC soit généré est :</para>
-
- <para>
- <command><filename>/usr/local/bin/logstuff</filename> <filename>/var/log/slony1/archivelogs/payroll/slony1_log_1_00000000000000000036.sql</filename></command>
- </para>
-
- <warning><para>Notons que cette commande est lancée avec la fonction
- <function>system(const char *COMMAND)</function> ; si le programme
- exécuté dure 5 minutes, cela retardera le prochain
- <command>SYNC</command> de cinq minutes. Vous devez vous assurer
- que la commande d'archivage ne fait pas de choses trop
- <quote>compliquées</quote>.</para></warning>
-
- </listitem>
- </varlistentry>
-
- </variablelist>
-</sect1>
-<sect1 id="slon-config-interval">
- <title>Configuration des évènements</title>
- <variablelist>
- <varlistentry id="slon-config-sync-interval" xreflabel="slon_conf_sync_interval">
- <term><varname>sync_interval</varname> (<type>entier</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>sync_interval</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Fréquence maximale (en millisecondes) de vérification des mises à jour.
- Valeurs possibles : de 10 à 60000, La valeur par défaut est 100.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-sync-interval-timeout" xreflabel="slon_conf_sync_interval_timeout">
- <term><varname>sync_interval_timeout</varname> (<type>entier</type>)
- <indexterm>
- <primary>paramètre de configuration<varname>sync_interval_timeout</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>
- Délai maximal, en millisecondes, avant qu'un événement
- <command>SYNC</command> soit déclenché. Ceci évite les
- situations de compétition (« race conditions ») lorsqu'une
- séquence d'actions est lancée par un trigger alors que des
- lignes très longues sont insérées, ce qui fait que la séquence d'action
- est immédiatement visible pour le processus de synchronisation
- alors que les lignes insérées ne sont pas encore visibles.
- Si l'événement <command>SYNC</command> est attrapé
- par un nœud abonné, puis traité et terminé avant que la
- transaction ne soit validée, les changements de cette
- transaction ne seront pas répliqués avant le
- <command>SYNC</command> suivant. Cependant, si
- toutes les applications s'arrêtent soudainement, il n'y
- aura plus de séquence d'actions, et les vérifications
- fréquentes avec <option>-s</option> n'y feront rien.
- Ainsi, il est nécessaire d'avoir un paramètre
- <envar>sync_interval_timeout</envar>.
- Valeurs possibles : [0-120000]. Valeur par défaut : 1000.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-sync-group-maxsize" xreflabel="slon_conf_sync_group_maxsize">
- <term><varname>sync_group_maxsize</varname> (<type>entier</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>sync_group_maxsize</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>
- Nombre maximum d'événements <command>SYNC</command> qui seront regroupés
- ensemble lorsqu'un nœud abonné tombe en panne.
- Les événements <command>SYNC</command>s ne sont empaquetés
- que s'ils sont nombreux et qu'ils sont contiguës.
- S'il n'y qu'un seul événement <command>SYNC</command> disponible,
- même l'option <option>-g60</option> s'appliquera à cet évènement unique.
- Dès qu'un nœud abonné rattrape son retard, il appliquera chaque événement
- <command>SYNC</command> individuellement.
- Valeurs possibles : [0,10000]. Valeur par défaut : 20.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-vac-frequency" xreflabel="slon_conf_vac_frequency">
- <term><varname>vac_frequency</varname> (<type>entier</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>vac_frequency</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>
- Définit le nombre de cycles de nettoyage lancés avant qu'un
- VACUUM ne soit exécuté. O désactive les VACUUM internes, utilisés
- avec le démon <application>pg_autovacuum</application>.
- Valeurs possibles : [0,100]. Valeur par défaut : 3.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-cleanup-interval" xreflabel="slon_config_cleanup_interval">
- <term><varname>cleanup_interval</varname> (<type>interval</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>cleanup_interval</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>
- Contrôle à quelle fréquence les vieux événements doivent être effacés.
- En corollaire, cela contrôle le nettoyage des tables
- <envar>sl_log_1</envar> et <envar>sl_log_2</envar>.
- Valeur par défaut : '10 minutes'.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-cleanup-deletelogs" xreflabel="slon_conf_cleanup_deletelogs">
- <term><varname>cleanup_deletelogs</varname> (<type>booléen</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>cleanup_deletelogs</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>
- Contrôle si la commande DELETE est utilisée (ou pas) pour effacer les anciennes données
- à l'intérieur des tables <envar>sl_log_1</envar> et <envar>sl_log_2</envar>.
- Valeur par défaut : false.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-desired-sync-time" xreflabel="desired_sync_time">
- <term><varname>desired_sync_time</varname> (<type>entier</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>desired_sync_time</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Temps maximum prévu pour un groupe d'événements
- <command>SYNC</command>. Si la réplication est en retard,
- <application>slon</application> essaie d'augmenter le nombre
- de SYNC en évaluant le temps d'exécution qu'ils auraient du prendre.
- Valeurs possibles : [10000,600000] ms. Valeur par défaut : 60000.</para>
-
- <para>Si cette valeur est à 0, alors ce mécanisme est désactivé.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-quit-sync-provider" xreflabel="quit_sync_provider">
- <term><varname>quit_sync_provider</varname> (<type>entier</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>quit_sync_provider</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Ce paramètre doit être utilisé conjointement avec <xref
- linkend="slon-config-quit-sync-finalsync"/>. Il indique
- le processus du nœud fournisseur à surveiller pour
- savoir si le slon doit s'arrêter après avoir atteint le numéro d'un
- événement <quote>final</quote>.</para>
-
- <para>Si cette valeur est à 0, alors ce mécanisme est désactivé.</para>
- </listitem>
- </varlistentry>
- <varlistentry id="slon-config-quit-sync-finalsync" xreflabel="quit_sync_finalsync">
- <term><varname>quit_sync_finalsync</varname> (<type>entier</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>quit_sync_finalsync</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Numéro de l'événement final à traiter. Ceci
- doit être utilisé en conjonction avec <xref linkend="slon-config-quit-sync-finalsync"/>,
- et permet à <application>slon</application> de s'arrêter lorsqu'il atteint
- un certain événement sur le nœud fournisseur.</para>
-
- <para>Si cette valeur est à 0, alors ce mécanisme est désactivé.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-lag-interval" xreflabel="lag_interval">
- <term><varname>lag_interval</varname> (<type>chaîne/interval</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>lag_interval</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Indique un intervalle à partir duquel le nœud
- est en décalage avec son fournisseur. Si cette valeur est définie,
- elle est utilisée dans la boucle de gestion des événements
- afin de modifier la priorité des événements dans la file d'attente ;
- les événements plus récents que <command>now() -
- lag_interval::interval</command> sont laissés de côté afin d'être
- traités plus tard.</para>
-
- <para>Si cette valeur est vide, alors ce mécanisme est désactivé.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-max-rowsize" xreflabel="sync_max_rowsize">
- <term><varname>sync_max_rowsize</varname> (<type>entier</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>sync_max_rowsize</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Taille à partir de laquelle le champ <envar>log_cmddata</envar> d'une ligne d'une
- table sl_log_? est considéré comme volumineux.
- Jusqu'à 500 lignes de cette taille sont autorisées en mémoire à
- un instant t. Les lignes plus larges sont comptées dans l'espace
- d'allocation <envar>sync_max_largemem</envar> et libérées à la demande (avec
- la fonction <function>free()</function>).
- </para>
-
- <para>La valeur par défaut est 8192, ce qui signifie que la consommation
- mémoire (pour le curseur de LOG) ne doit pas dépasser 8 Mo.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-max-largemem" xreflabel="sync_max_largemem">
- <term><varname>sync_max_largemem</varname> (<type>entier</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>sync_max_largemem</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Taille maximum de la mémoire allouée pour les lignes volumineuses
- quand <envar>log_cmddata</envar> est plus grand que
- <envar>sync_max_rowsize</envar>.</para>
-
- <para>Notez que l'algorithme lit les lignes jusqu'à ce que la valeur soit
- <emphasis>dépassée</emphasis>. Sinon, une ligne plus large que cette valeur bloquerait la
- réplication. En conséquence, ne supposez pas que la consommation mémoire restera
- inférieure à cette valeur.
- </para>
-
- <para>La valeur par défaut est 5242880.</para>
- </listitem>
- </varlistentry>
- <varlistentry id="slon-config-remote-listen-timeout" xreflabel="slon_conf_remote_listen_timeout">
- <term><varname>remote_listen_timeout</varname> (<type>entier</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>remote_listen_timeout</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>Durée que le processus d'écoute distant doit attendre avant
- de considérer qu'un événement est périmé.
- Valeurs possibles : [30-30000]. Valeur par défaut : 300.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-</sect1>
-</article>
Copied: traduc/tags/slony_1_2_12/slonconf.xml (from rev 1244, traduc/trunk/slony/slonconf.xml)
===================================================================
--- traduc/tags/slony_1_2_12/slonconf.xml (rev 0)
+++ traduc/tags/slony_1_2_12/slonconf.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,488 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<article id="runtime-config">
+ <title>Configuration</title>
+ <indexterm>
+ <primary>configuration</primary>
+ <secondary>du démon slon</secondary>
+ </indexterm>
+
+ <para>
+ Il existe plusieurs paramètres de configuration qui affectent le comportement
+ du système de réplication. Dans cette section, nous allons décrire
+ comment définir les paramètres de configuration du démon
+ <application>slon</application> ; La sous-section qui suit détaille
+ chaque paramètre :
+ </para>
+
+ <para>
+ Tous les noms de paramètres sont sensibles à la casse des lettres.
+ Chaque paramètre se voir assigner un type : booléen,
+ entier, flottant ou chaîne de caractères. Les valeurs booléennes
+ peuvent être <literal>ON</literal>, <literal>OFF</literal>,
+ <literal>FALSE</literal>, <literal>YES</literal>, <literal>NO</literal>,
+ <literal>1</literal>, <literal>0</literal> (toutes en majuscule) ou
+ n'importe quel préfixe non ambigü de ces valeurs.
+ </para>
+
+ <para>
+ On spécifie un paramètre par ligne. Le signe égal entre le nom
+ et la valeur est optionnel. Les espaces ne sont pas
+ significatifs et les lignes vides sont ignorées.
+ Le caractère dièse (<literal>#</literal>) permet de placer
+ un commentaire n'importe où. Les valeurs des paramètres qui ne
+ sont pas des identifiant ou des nombres doivent être encadrées
+ par des guillemets simples.
+ </para>
+
+ <para>
+ Certaines options peuvent être définies en ligne de commande,
+ ces options surchargent les paramètres identiques qui se trouvent
+ dans le fichier de configuration.
+ </para>
+
+
+<sect1 id="slon-config-logging">
+ <title>Traces</title>
+ <variablelist>
+ <varlistentry id="slon-config-logging-syslog" xreflabel="slon_conf_syslog">
+ <term>
+ <varname>syslog</varname> (<type>entier</type>)
+ <indexterm>
+ <primary>paramètre de configuration de <varname>syslog</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Active les traces avec syslog. Si le paramètre vaut 1, les messages vont
+ à la fois vers syslog et la sortie standard. La valeur 2 envoie les traces
+ uniquement à syslog. Toutefois, certains messages seront toujours envoyés
+ sur la sortie standard ou sur la sortie des erreurs. Par défaut, ce paramètre
+ est à 0, ce qui signifie que syslog est désactivé.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry id="slon-config-logging-syslog-facility" xreflabel="slon_conf_syslog_facility">
+ <term>
+ <varname>syslog_facility</varname> (<type>chaîne</type>)
+ <indexterm>
+ <primary>paramètre de configuration de <varname>syslog_facility</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Positionne la <quote>facility</quote> que syslog devra utiliser.
+ Les valeurs valides sont LOCAL0, LOCAL1, LOCAL2,
+ LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. La valeur par défaut est
+ LOCAL0.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-logging-syslog-ident" xreflabel="slon_conf_syslog_ident">
+ <term>
+ <varname>syslog_ident</varname> (<type>chaîne</type>)
+ <indexterm>
+ <primary>Paramètre de configuration de <varname>syslog_ident</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Définit le nom du programme utilisé pour identifier les messages slon
+ dans syslog. La valeur par défaut est slon.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-logging-log-level" xreflabel="lon_conf_log_level">
+ <term>
+ <varname>log_level</varname> (<type>entier</type>)
+ <indexterm>
+ <primary>Paramètre de configuration du <varname>log_level</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Niveau de traces de débogage (plus la valeur est haute, plus les
+ messages sont verbeux).
+ Valeurs possibles : de 0 à 4. Valeur par défaut : 2.</para>
+
+ <para>Il y a <link linkend="nineloglevels">neuf niveaux de messages
+ de trace</link> ; en utilisant cette option, une partie ou l'ensemble
+ des niveaux <quote>debug</quote> peut être désactivé.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-logging-log-pid" xreflabel="slon_conf_log_pid">
+ <term>
+ <varname>log_pid</varname> (<type>booléen</type>)
+ <indexterm>
+ <primary>paramètre de configuration du <varname>log_pid</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Détermine si le PID du processus père slon
+ doit apparaître dans chaque ligne du journal applicatif.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-logging-log-timestamp" xreflabel="slon_conf_log_timestamp">
+ <term>
+ <varname>log_timestamp</varname> (<type>booléen</type>)
+ <indexterm>
+ <primary>paramètre de configuration de <varname>log_timestamp</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Détermine si l'horodatage de chaque événement doit
+ apparaître dans chaque ligne du journal applicatif.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-logging-log-timestamp-format" xreflabel="slon_conf_log_timestamp_format">
+ <term>
+ <varname>log_timestamp_format</varname> (<type>chaîne</type>)
+ <indexterm>
+ <primary>paramètre de configuration du <varname>log_timestamp_format</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Une chaîne au format conforme avec <function>strftime()</function>
+ qui sera utilisé si <envar>log_timestamp</envar> est activé.
+ La valeur par défaut est <quote>%Y-%m-%d %H:%M:%S %Z</quote></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-logging-pid-file" xreflabel="slon_conf_log_pid_file">
+ <term>
+ <varname>pid_file</varname> (<type>chaîne</type>)
+ <indexterm>
+ <primary>paramètre de configuration du <varname>pid_file</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>L'emplacement et le nom du fichier où vous souhaitez
+ stocker le PID du processus slon. La valeur par défaut n'est
+ pas définie, ce qui implique qu'aucun fichier n'est écrit.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+</sect1>
+
+<sect1 id="slon-config-connection">
+ <title>Paramètres de connexion</title>
+ <variablelist>
+ <varlistentry id="slon-config-connection-cluster-name" xreflabel="slon_conf_cluster_name">
+ <term>
+ <varname>cluster_name</varname> (<type>chaîne</type>)
+ <indexterm>
+ <primary>paramètre de configuration <varname>cluster_name</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Définit le nom du cluster que l'instance de
+ <application>slon</application> doit gérer.
+ Par défaut, cette valeur est obtenue en ligne de commande.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-connection-conn-info" xreflabel="slon_conf_conn_info">
+ <term><varname>conn_info</varname> (<type>chaîne</type>)
+ <indexterm>
+ <primary>paramètre de configuration <varname>conn_info</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Définit les informations de connexion pour <application>slon</application>.
+ Par défaut, cette valeur est obtenue en ligne de commande.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-sql-on-connection" xreflabel="slon_conf_sql_on_connection">
+ <term><varname>sql_on_connection</varname> (<type>chaîne</type>)
+ <indexterm>
+ <primary>paramètre de configuration de <varname>sql_on_connection</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Exécute cette requête SQL sur chaque nœud lorsque
+ <application>slon</application> s'y connecte. Utile pour
+ définir un niveau de trace, ou pour configurer les
+ paramètres du planificateur ou de la mémoire.
+ Vous pouvez spécifier de multiples requêtes en les
+ séparant par un point-virgule.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+</sect1>
+<sect1 id="slon-archive-logging">
+ <title>Options d'archivage</title>
+ <variablelist>
+ <varlistentry id="slon-config-archive-dir" xreflabel="slon_conf_archive_dir">
+ <term><varname>archive_dir</varname> (<type>text</type>)
+ <indexterm>
+ <primary>paramètre de configuration <varname>archive_dir</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Ceci indique dans quel répertoire les fichiers d'archivages des SYNC doivent
+ être stockés.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-command-on-logarchive" xreflabel="slon_conf_command_on_log_archive">
+ <term><varname>command_on_logarchive</varname> (<type>texte</type>)
+ <indexterm>
+ <primary>paramètre de configuration de <varname>command_on_logarchive</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Ce paramètre définit une commande Unix qui sera exécutée à
+ chaque fois qu'un fichier d'archive est produit.
+ </para>
+
+ <para>Un paramètre est passé à cette commande : le chemin absolu
+ du fichier d'archive. Ainsi, si on imagine la configuration suivante :
+ </para>
+
+ <para>
+ <command>command_on_logarchive = <filename>/usr/local/bin/logstuff</filename></command>
+ </para>
+ <para>
+ <command>archive_dir = <filename>/var/log/slony1/archivelogs/payroll</filename></command>
+ </para>
+
+ <para>Un fichier de d'archive sera nommé de cette façon :
+ <filename>/var/log/slony1/archivelogs/payroll/slony1_log_1_00000000000000000036.sql</filename></para>
+
+ <para>La commande exécutée après que le SYNC soit généré est :</para>
+
+ <para>
+ <command><filename>/usr/local/bin/logstuff</filename> <filename>/var/log/slony1/archivelogs/payroll/slony1_log_1_00000000000000000036.sql</filename></command>
+ </para>
+
+ <warning><para>Notons que cette commande est lancée avec la fonction
+ <function>system(const char *COMMAND)</function> ; si le programme
+ exécuté dure 5 minutes, cela retardera le prochain
+ <command>SYNC</command> de cinq minutes. Vous devez vous assurer
+ que la commande d'archivage ne fait pas de choses trop
+ <quote>compliquées</quote>.</para></warning>
+
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+</sect1>
+<sect1 id="slon-config-interval">
+ <title>Configuration des évènements</title>
+ <variablelist>
+ <varlistentry id="slon-config-sync-interval" xreflabel="slon_conf_sync_interval">
+ <term><varname>sync_interval</varname> (<type>entier</type>)
+ <indexterm>
+ <primary>paramètre de configuration <varname>sync_interval</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Fréquence maximale (en millisecondes) de vérification des mises à jour.
+ Valeurs possibles : de 10 à 60000, La valeur par défaut est 100.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-sync-interval-timeout" xreflabel="slon_conf_sync_interval_timeout">
+ <term><varname>sync_interval_timeout</varname> (<type>entier</type>)
+ <indexterm>
+ <primary>paramètre de configuration<varname>sync_interval_timeout</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Délai maximal, en millisecondes, avant qu'un événement
+ <command>SYNC</command> soit déclenché. Ceci évite les
+ situations de compétition (« race conditions ») lorsqu'une
+ séquence d'actions est lancée par un trigger alors que des
+ lignes très longues sont insérées, ce qui fait que la séquence d'action
+ est immédiatement visible pour le processus de synchronisation
+ alors que les lignes insérées ne sont pas encore visibles.
+ Si l'événement <command>SYNC</command> est attrapé
+ par un nœud abonné, puis traité et terminé avant que la
+ transaction ne soit validée, les changements de cette
+ transaction ne seront pas répliqués avant le
+ <command>SYNC</command> suivant. Cependant, si
+ toutes les applications s'arrêtent soudainement, il n'y
+ aura plus de séquence d'actions, et les vérifications
+ fréquentes avec <option>-s</option> n'y feront rien.
+ Ainsi, il est nécessaire d'avoir un paramètre
+ <envar>sync_interval_timeout</envar>.
+ Valeurs possibles : [0-120000]. Valeur par défaut : 1000.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-sync-group-maxsize" xreflabel="slon_conf_sync_group_maxsize">
+ <term><varname>sync_group_maxsize</varname> (<type>entier</type>)
+ <indexterm>
+ <primary>paramètre de configuration <varname>sync_group_maxsize</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Nombre maximum d'événements <command>SYNC</command> qui seront regroupés
+ ensemble lorsqu'un nœud abonné tombe en panne.
+ Les événements <command>SYNC</command>s ne sont empaquetés
+ que s'ils sont nombreux et qu'ils sont contiguës.
+ S'il n'y qu'un seul événement <command>SYNC</command> disponible,
+ même l'option <option>-g60</option> s'appliquera à cet évènement unique.
+ Dès qu'un nœud abonné rattrape son retard, il appliquera chaque événement
+ <command>SYNC</command> individuellement.
+ Valeurs possibles : [0,10000]. Valeur par défaut : 20.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-vac-frequency" xreflabel="slon_conf_vac_frequency">
+ <term><varname>vac_frequency</varname> (<type>entier</type>)
+ <indexterm>
+ <primary>paramètre de configuration <varname>vac_frequency</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Définit le nombre de cycles de nettoyage lancés avant qu'un
+ VACUUM ne soit exécuté. O désactive les VACUUM internes, utilisés
+ avec le démon <application>pg_autovacuum</application>.
+ Valeurs possibles : [0,100]. Valeur par défaut : 3.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-desired-sync-time" xreflabel="desired_sync_time">
+ <term><varname>desired_sync_time</varname> (<type>entier</type>)
+ <indexterm>
+ <primary>paramètre de configuration <varname>desired_sync_time</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Temps maximum prévu pour un groupe d'événements
+ <command>SYNC</command>. Si la réplication est en retard,
+ <application>slon</application> essaie d'augmenter le nombre
+ de SYNC en évaluant le temps d'exécution qu'ils auraient du prendre.
+ Valeurs possibles : [10000,600000] ms. Valeur par défaut : 60000.</para>
+
+ <para>Si cette valeur est à 0, alors ce mécanisme est désactivé.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-quit-sync-provider" xreflabel="quit_sync_provider">
+ <term><varname>quit_sync_provider</varname> (<type>entier</type>)
+ <indexterm>
+ <primary>paramètre de configuration <varname>quit_sync_provider</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Ce paramètre doit être utilisé conjointement avec <xref
+ linkend="slon-config-quit-sync-finalsync"/>. Il indique
+ le processus du nœud fournisseur à surveiller pour
+ savoir si le slon doit s'arrêter après avoir atteint le numéro d'un
+ événement <quote>final</quote>.</para>
+
+ <para>Si cette valeur est à 0, alors ce mécanisme est désactivé.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry id="slon-config-quit-sync-finalsync" xreflabel="quit_sync_finalsync">
+ <term><varname>quit_sync_finalsync</varname> (<type>entier</type>)
+ <indexterm>
+ <primary>paramètre de configuration <varname>quit_sync_finalsync</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Numéro de l'événement final à traiter. Ceci
+ doit être utilisé en conjonction avec <xref linkend="slon-config-quit-sync-finalsync"/>,
+ et permet à <application>slon</application> de s'arrêter lorsqu'il atteint
+ un certain événement sur le nœud fournisseur.</para>
+
+ <para>Si cette valeur est à 0, alors ce mécanisme est désactivé.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-lag-interval" xreflabel="lag_interval">
+ <term><varname>lag_interval</varname> (<type>chaîne/interval</type>)
+ <indexterm>
+ <primary>paramètre de configuration <varname>lag_interval</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Indique un intervalle à partir duquel le nœud
+ est en décalage avec son fournisseur. Si cette valeur est définie,
+ elle est utilisée dans la boucle de gestion des événements
+ afin de modifier la priorité des événements dans la file d'attente ;
+ les événements plus récents que <command>now() -
+ lag_interval::interval</command> sont laissés de côté afin d'être
+ traités plus tard.</para>
+
+ <para>Si cette valeur est vide, alors ce mécanisme est désactivé.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-max-rowsize" xreflabel="sync_max_rowsize">
+ <term><varname>sync_max_rowsize</varname> (<type>entier</type>)
+ <indexterm>
+ <primary>paramètre de configuration <varname>sync_max_rowsize</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Taille à partir de laquelle le champ <envar>log_cmddata</envar> d'une ligne d'une
+ table sl_log_? est considéré comme volumineux.
+ Jusqu'à 500 lignes de cette taille sont autorisées en mémoire à
+ un instant t. Les lignes plus larges sont comptées dans l'espace
+ d'allocation <envar>sync_max_largemem</envar> et libérées à la demande (avec
+ la fonction <function>free()</function>).
+ </para>
+
+ <para>La valeur par défaut est 8192, ce qui signifie que la consommation
+ mémoire (pour le curseur de LOG) ne doit pas dépasser 8 Mo.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="slon-config-max-largemem" xreflabel="sync_max_largemem">
+ <term><varname>sync_max_largemem</varname> (<type>entier</type>)
+ <indexterm>
+ <primary>paramètre de configuration <varname>sync_max_largemem</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Taille maximum de la mémoire allouée pour les lignes volumineuses
+ quand <envar>log_cmddata</envar> est plus grand que
+ <envar>sync_max_rowsize</envar>.</para>
+
+ <para>Notez que l'algorithme lit les lignes jusqu'à ce que la valeur soit
+ <emphasis>dépassée</emphasis>. Sinon, une ligne plus large que cette valeur bloquerait la
+ réplication. En conséquence, ne supposez pas que la consommation mémoire restera
+ inférieure à cette valeur.
+ </para>
+
+ <para>La valeur par défaut est 5242880.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry id="slon-config-remote-listen-timeout" xreflabel="slon_conf_remote_listen_timeout">
+ <term><varname>remote_listen_timeout</varname> (<type>entier</type>)
+ <indexterm>
+ <primary>paramètre de configuration <varname>remote_listen_timeout</varname></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>Durée que le processus d'écoute distant doit attendre avant
+ de considérer qu'un événement est périmé.
+ Valeurs possibles : [30-30000]. Valeur par défaut : 300.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+</sect1>
+</article>
Deleted: traduc/tags/slony_1_2_12/slonik_ref.xml
===================================================================
--- traduc/trunk/slony/slonik_ref.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/slonik_ref.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,3015 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<article id="slonikref">
-<title>Tour d'horizon des commandes Slonik</title>
- <sect1><title>Introduction</title>
- <para><application>Slonik</application> est un utilitaire en ligne de commande
- conçu spécifiquement pour mettre en place et modifier la configuration
- du système de réplication &slony1;.</para>
- <sect2 id="outline">
- <title>Considérations générales</title>
- <para>
- L'utilitaire en ligne de commande <application>slonik</application>
- est supposé être intégré dans des scripts shell et lit
- les commandes à partir d'un fichier ou de stdin (voir plus
- bas pour des exemples). Presque tout le travail de configuration
- <emphasis>réel</emphasis> est effectué en appelant des procédures
- stockées après avoir chargé la base de support &slony1; dans
- la base de données. Vous pouvez trouver de la documentation sur
- ces procédures dans le chapitre <ulink url="schemadoc">Documentation
- du schéma de &slony1;</ulink>, ainsi que dans les commentaires
- qui sont associés aux procédures dans la base de données.
- </para>
- <para>
- <application>Slonik</application> a été créé car :
- <itemizedlist>
-
- <listitem><para>Les procédures stockées ont des besoins d'informations
- spécifiques telles que l'identifiant du nœud de réplication
- sur lequel elles sont appelées ;</para></listitem>
-
- <listitem><para>L'absence de paramètres nommés dans les
- procédures stockées rend difficile de faire cela depuis
- l'invite de commande <application>psql</application> ;
- </para></listitem>
-
- <listitem><para><application>psql</application> n'a pas la possibilité
- de maintenir plusieurs connexions avec des transactions ouvertes.
- </para></listitem>
- </itemizedlist>
- </para>
- <para>
-
- </para>
- <sect3><title>Commandes</title>
- <para>Le format du langage de commande slonik est libre.
- Les commandes commencent par des mots-clefs et sont terminées
- par un point-virgule. La plupart des commandes ont une liste de
- paramètres, certains ont une valeur par défaut et sont donc
- facultatifs. Les paramètres de commandes sont entourés par des
- parenthèses. Chaque option est constituée d'un ou plusieurs
- mots-clefs, suivis d'un symbole égal, suivi d'une valeur. Les
- options multiples à l'intérieur de parenthèses sont séparées par
- des virgules. Tous les mot-clefs sont sensibles à la casse. Le
- langage devrait rappeler le SQL.</para>
- <para>Les valeurs d'option peuvent être :</para>
- <itemizedlist>
- <listitem><para>des entiers ;</para></listitem>
- <listitem><para>des chaînes de caractères entourés de guillemets ;</para></listitem>
- <listitem><para>des valeurs booléennes {TRUE|ON|YES} ou {FALSE|OFF|NO} ;</para></listitem>
- <listitem><para>des mots-clefs dans des cas spécifiques.</para></listitem>
- </itemizedlist>
-
- </sect3>
- <sect3><title>Commentaires</title>
- <para>Les commentaires commencent par un dièse (#) et vont jusqu'à la fin de la ligne.</para>
- </sect3>
- <sect3><title>Groupes de commandes</title>
- <para>Les commandes peuvent être combinées par groupes de commandes avec une
- éventuellement une condition <command>on error</command> et
- <command>on success</command>.
- La syntaxe est la suivante :
- <programlisting>
- try {
- commands;
- }
- [on error { commands; }
- [on success { commands; }
- </programlisting></para>
-
- <para>Ces commandes sont regroupées ensemble au sein d'une transaction
- pour chaque nœud participant.</para>
- </sect3>
- </sect2>
- </sect1>
-</article>
-<!-- ************************************************************ -->
-<reference id="metacmds">
- <title>Méta-commandes Slonik</title>
- <partintro>
- <para>Les commandes suivantes sont utilisées pour séparer
- les définitions des composants des scripts Slonik ;
- <xref linkend="stmtinclude"/> regroupe la configuration
- dans des fichiers centraux qui peuvent être réutilisés, et
- <xref linkend="stmtdefine"/> permet de remplacer les identifiants
- numériques et ésotériques des objets par des identifiants mnémotechniques.</para>
- </partintro>
- <!-- **************************************** -->
- <refentry id ="stmtinclude">
- <refmeta><refentrytitle>INCLUDE</refentrytitle><manvolnum>7</manvolnum></refmeta>
- <refnamediv>
- <refname>INCLUDE</refname>
- <refpurpose>insérer du code slonik à partir d'un autre fichier</refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>include </command>
- <arg><replaceable class="parameter"><chemin></replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>Ceci injecte le script slonik spécifié à l'intérieur du script actuel.
- Si le <option>chemin</option> est relatif, <xref linkend="slonik"/>
- cherchera à partir du répertoire de travail.</para>
- <para>Les inclusions imbriquées sont supportées. Le scanner et l'analyseur
- retournent le bon nom de fichier et le numéro ligne correcte en cas
- d'erreur.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- include </tmp/preamble.slonik>;
- </programlisting>
- </refsect1>
- <refsect1><title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.1.</para>
- </refsect1>
- </refentry>
- <!-- **************************************** -->
- <refentry id ="stmtdefine"><refmeta><refentrytitle>DEFINE</refentrytitle><manvolnum>7</manvolnum></refmeta>
- <refnamediv><refname>DEFINE</refname>
- <refpurpose>Définir un nom symbolique</refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>define </command>
- <arg><replaceable class="parameter">nom</replaceable></arg>
- <arg><replaceable class="parameter">valeur</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>Ceci définit un nom symbolique. Les noms symboliques doivent
- respecter les règles de slonik en matière de construction d'identifiants,
- en commençant par une lettre, suivie de lettres, de nombres et de soulignés
- (« _ »).</para>
- <para>Les valeurs des noms symboliques peuvent contenir des espaces et peuvent contenir
- des références à des noms symboliques, de manière récursive.</para>
- <para>Les symboles sont référencés en utilisant une arobase <quote>@</quote> suivi
- du nom symbolique. Notons que le référencement d'un symbole est annulé
- à l'intérieur des chaînes de caractères.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- define cluster films;
- define sakai 1;
- define chen 2;
- define fqn fully qualified name;
-
- cluster name = @cluster;
- node @sakai admin conninfo = 'service=sakai-replication';
- node @chen admin conninfo = 'service=chen-replication';
- define setFilms id = 1;
- define sakaiFilms @setFilms, origin = @sakai;
-
- create set ( @sakaiFilms, comment = 'films' );
-
- set add table( set @sakaiFilms, id = 1, @fqn = 'public.clients',
- comment = 'sakai customers' );
- set add table( set @sakaiFilms, id = 2, @fqn = 'public.cassettes',
- comment = 'sakai cassettes' );
- echo '@sakaiFilms sera affiché comme une chaîne, et ne sera pas interprété';
- </programlisting>
- </refsect1>
-
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.1.</para>
- </refsect1>
- </refentry>
-</reference>
-
-<!-- **************************************** -->
-
-<reference id="hdrcmds">
- <title>Commandes slonik préliminaires</title>
- <partintro>
- <para>Les commandes suivantes doivent apparaître en <quote>préambule</quote>
- de chaque script de commande <application>slonik</application>.
- Ils ne provoquent aucune action directement sur les nœuds du
- système de réplication, mais affecte l'exécution du script tout entier.</para>
- </partintro>
- <refentry id ="clustername">
- <refmeta><refentrytitle>CLUSTER NAME</refentrytitle><manvolnum>7</manvolnum></refmeta>
- <refnamediv>
- <refname>CLUSTER NAME</refname>
- <refpurpose>préambule - identifier le cluster &slony1;</refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>CLUSTER NAME = </command>
- <arg><replaceable class="parameter">nom</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>Ceci doit être la toute première ligne de chaque script
- <application>slonik</application>. Elle définit le schéma
- dans lequel toutes les fonctions spécifiques, les procédures,
- les tables et les séquences de &slony1; sont déclarées.
- Le nom du schéma est construit en préfixant la chaîne
- de caractères fournie par un souligné. Ce schéma sera
- identique sur toutes les bases de données qui participent
- au même groupe de réplication.</para>
-
- <para>Aucun objet utilisateur n'est supposé être placé dans ce schéma,
- et ce schéma ne doit pas exister avant l'ajout de la base de données
- dans le système de réplication. Ainsi, si vous ajoutez un nouveau nœud
- en utilisant <command>pg_dump -s</command> sur une base qui est déjà
- dans le cluster de réplication, vous devrez supprimer le schéma
- avec la commande SQL <command> DROP SCHEMA _testcluster CASCADE;</command>.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- CLUSTER NAME = testcluster;
- </programlisting>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
- <refentry id ="admconninfo">
- <refmeta><refentrytitle>ADMIN CONNINFO</refentrytitle><manvolnum>7</manvolnum></refmeta>
- <refnamediv>
- <refname>ADMIN CONNINFO</refname>
- <refpurpose>preambule - identifier la base &postgres;</refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>NODE ival ADMIN CONNINFO = 'DSN';</command>
- <arg><replaceable class="parameter">ival</replaceable></arg>
- <arg><replaceable class="parameter">'conninfo'</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>Décrit comment l'utilitaire <application>slonik</application> peut
- atteindre les bases des nœuds du cluster à partir de l'endroit
- où il se trouve (en général le poste de travail de l'administrateur).
- La chaîne connifo est l'argument passé à la fonction
- libpq <function>PQconnectdb()</function>. L'utilisateur qui se connecte
- doit être un super-utilisateur spécifique à la réplication car certaines
- actions réalisées par la suite comprennent des opérations strictement réservées
- aux super-utilisateurs du serveur &postgres;.</para>
-
- <para>L'utilitaire <application>slonik</application> n'essaie de se connecter
- à une base de donnée que si une commande nécessite une connexion.</para>
-
- <note><para>Comme indiqué dans les document originaux, &slony1; est conçu comme
- un système de réplication d'entreprises pour centres de données. Lors du développement
- du logiciel, on présuppose que les serveurs de bases de données et les postes
- de travail impliqués dans la réplication et/ou dans les activités de mise en place et
- de configuration peuvent utiliser des méthodes simples d'authentification telle que
- <quote>trust</quote>. Cependant, libpq peut lire les mots de passe dans le fichier
- <filename>.pgpass</filename>.</para></note>
- <note><para>Si vous devez changer les informations DSN pour un nœud, par exemple si
- l'adresse IP d'un hôte est modifiée, vous devez soumettre cette nouvelle
- information avec la commande <xref linkend="stmtstorepath"/>,
- et la configuration sera propagée. Certains processus
- <application>slon</application> existant devront être relancés afin qu'ils
- soient avertis de ce changement de configuration.</para></note>
-
- <para>Pour plus de détails sur la distinction entre ceci et <xref
- linkend="stmtstorepath"/>, consultez le chapitre &rplainpaths;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
- </programlisting>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-</reference>
-
-<!-- ************************************************************ -->
-<reference id="cmds">
- <title>Commande de configuration et d'action</title>
- <refentry id ="stmtecho">
- <refmeta>
- <refentrytitle>ECHO</refentrytitle><manvolnum>7</manvolnum></refmeta>
- <refnamediv>
- <refname>ECHO</refname>
- <refpurpose>Outil générique de sortie</refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>echo</command>
- <arg><replaceable class="parameter">'message'</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>Affiche un message littéral sur la sortie standard.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- ECHO 'Nœud 1 initialisé correctement';
- </programlisting>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
- <!-- **************************************** -->
-
- <refentry id ="stmtexit"><refmeta><refentrytitle>EXIT</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>EXIT</refname>
-
- <refpurpose>Termine un script Slonik avec un signal</refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>exit</command>
- <arg><replaceable class="parameter"> [-]ival</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>
- Termine immédiatement un script d'exécution, annulant toute
- les transactions ouvertes (ROLLBACK) sur toutes les bases de données
- connectées. L'utilitaire <application>slonik</application> retournera
- la valeur indiquée comme code de terminaison du programme.
- </para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- EXIT 0;
- </programlisting>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
- <!-- **************************************** -->
- <refentry id="stmtinitcluster">
- <refmeta>
- <refentrytitle>INIT CLUSTER</refentrytitle>
- <manvolnum>7</manvolnum>
- </refmeta>
- <refnamediv>
- <refname>INIT CLUSTER</refname>
- <refpurpose>Initialise le cluster &slony1;</refpurpose></refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>INIT CLUSTER</command>
- <arg>ID = <replaceable class="parameter">entier</replaceable></arg>
- <arg>COMMENT = <replaceable class="parameter">'chaîne'</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para> Initialise le premier nœud d'un nouveau cluster de réplication &slony1;.
- Le processus d'initialisation consiste à créer le schéma du cluster, à
- charger toutes les tables, les fonctions, les procédures et à initialiser le nœud
- avec &funinitializelocalnode; et &funenablenode;.
-
- <variablelist>
- <varlistentry><term><literal>ID</literal></term>
- <listitem><para>L'identifiant numérique et unique du nœud.</para></listitem>
- </varlistentry>
-
- <varlistentry><term><literal>COMMENT = 'commentaire'</literal></term>
- <listitem><para>Un texte descriptif ajouté à la ligne du nœud dans
- la table &slnode;.
- </para></listitem>
- </varlistentry>
- </variablelist>
-
- </para>
-
- <para>Pour que ce processus fonctionne, les scripts SQL du système
- &slony1; doivent être installés sur le poste de travail de l'administrateur
- (l'ordinateur utilisé pour exécuter l'utilitaire <application>slonik</application>),
- tandis que sur le serveur qui héberge le nœud de base de donnée contenant les
- objets partagés, &slony1; doit être installé dans le répertoire qui contient
- les bibliothèques de &postgres;. De plus le langage procédural
- PL/pgSQL doit être installé au préalable sur la base de données cible.
- </para>
- </refsect1>
- <refsect1>
- <title>Exemple</title>
- <programlisting>
-INIT CLUSTER (
- ID = 1,
- COMMENT = 'Nœud 1'
-);
- </programlisting>
-
- <note> <para> Cette commande fonctionne de manière similaire à
- <xref linkend="stmtstorenode"/>, la différence étant que <command>INIT
- CLUSTER</command> n'a pas besoin de récupérer la configuration des autres nœuds.
- </para> </note>
- <note> <para>Soyez conscients que certains objets qui sont créés contiennent
- le nom du cluster à l'intérieur de leur nom (notamment, les index
- partiels sur <envar>sl_log_1</envar> et <envar>sl_log_2</envar>).
- Ceci implique que les noms de cluster <emphasis>très longs</emphasis>
- sont une mauvaise idée car ils entraînent un dépassement des noms
- d'objets au delà de la limite de 63 caractères.
- </para> </note>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Cette commande crée un nouveau schéma et configure les
- tables à l'intérieur ; aucun objet public ne doit être verrouillé
- pendant l'exécution de cette commande.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id ="stmtstorenode"><refmeta><refentrytitle>STORE NODE</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>STORE NODE</refname>
- <refpurpose>Initialise un nœud &slony1;</refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>STORE NODE (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Initialise un nouveau nœud et l'ajoute dans la configuration du
- cluster existant.</para>
-
- <para>Le processus d'initialisation consiste à la création du schéma
- sur le nouveau nœud (la base elle-même doit déjà exister), au
- chargement des tables, des fonctions, des procédures et à l'initialisation
- du nœud. La configuration existante du reste du nœud est copiée
- à partir d'un <quote>nœud d'événement</quote>.
-
- <variablelist>
- <varlistentry><term><literal>ID = ival</literal></term>
- <listitem><para>L'identifiant numérique et unique du nouveau nœud.</para></listitem>
- </varlistentry>
-
- <varlistentry><term><literal> COMMENT = 'description' </literal></term>
- <listitem><para>Un texte descriptif ajouté à la ligne du nœud dans
- la table &slnode;</para></listitem>
- </varlistentry>
-
- <varlistentry><term><literal>SPOOLNODE = booléen</literal></term>
-
- <listitem><para>Spécifie qu'un nœud est un nœud virtuel de récupération
- pour l'archivage de journaux de réplication. Si ce paramètre est à true,
- <application>slonik</application> n'essaiera pas d'initialiser la base de
- donnée avec le schéma de réplication.</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>EVENT NODE = ival</literal></term>
-
- <listitem><para>L'identifiant du nœud utilisé pour créer l'événement de configuration,
- qui prévient tous les nœuds existants de l'arrivée du nouveau nœud.
- La valeur par défaut est 1.</para></listitem>
- </varlistentry>
- </variablelist>
- </para>
-
- <para>Ceci utilise &funinitializelocalnode; et &funenablenode;.</para>
-
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- STORE NODE ( ID = 2, COMMENT = 'Nœud 2');
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Cette commande crée un nouveau schéma et configure les tables
- à l'intérieur ; aucun objet public ne doit être verrouillé
- pendant l'exécution de cette commande.</para>
- </refsect1>
-
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0. Le paramètre <envar>SPOOLNODE</envar>
- fut introduit dans la version 1.1 mais n'était pas implémentée dans cette version.
- La fonctionnalité <envar>SPOOLNODE</envar> est arrivée dans la
- version 1.2.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
- <refentry id="stmtdropnode"><refmeta><refentrytitle>DROP NODE</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>DROP NODE</refname>
-
- <refpurpose>Supprime un nœud de la réplication</refpurpose></refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>DROP NODE (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>
- Supprime un nœud. Cette commande retire complètement le nœud spécifié
- de la configuration du système de réplication.
- Si le démon de réplication est toujours en fonctionnement sur ce nœud
- (et qu'ils traitent les événements), il tentera de désinstaller le système
- de réplication et s'arrêtera de lui-même.
-
- <variablelist>
- <varlistentry><term><literal> ID = ival </literal></term>
- <listitem><para>L'identifiant du nœud à supprimer.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal> EVENT NODE = ival </literal></term>
- <listitem><para>L'identifiant du nœud qui génère l'événement. La valeur par défaut est 1.
- </para></listitem>
- </varlistentry>
- </variablelist>
- </para>
-
- <para>Cette commande utilise &fundropnode;.</para>
-
- <para>Quand vous invoquez <command>DROP NODE</command>, une des étapes
- consiste à lancer <command>UNINSTALL NODE</command>.</para>
-
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- DROP NODE ( ID = 2 );
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Lorsqu'on supprime des triggers d'une table de l'application,
- cela nécessite un accès exclusif à chaque table répliquée sur le nœud
- que l'on supprime.</para>
- </refsect1>
- <refsect1><title>Comportement dangereux ou non-intuitif</title>
- <para>Si vous utilisez des connexions qui cachent les plans d'exécution
- (ce qui est particulièrement commun pour les frameworks applicatifs Java utilisant
- des pools de connexions), les connexions peuvent cacher des plans
- de requêtes qui se basent sur une vision pré-<command>DROP NODE</command>,
- ce qui implique que vous obtiendrez des &rmissingoids;.</para>
-
- <para>Ainsi après avoir supprimé un nœud, il est préférable de réinitialiser
- les connexions de votre applications.</para>
-
- <para>Vous ne pouvez pas soumettre cela à un <command>EVENT
- NODE</command> ayant le même numéro que le nœud que vous supprimez ;
- la requête doit aller vers un nœud qui restera dans le cluster.
- </para>
- </refsect1>
-
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
- <refentry id="stmtuninstallnode"><refmeta><refentrytitle>UNINSTALL NODE</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>UNINSTALL NODE</refname>
-
- <refpurpose>Désinstaller un nœud &slony1;</refpurpose></refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>UNINSTALL NODE (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Restaure toutes les tables dans leur état non verrouillé, avec
- les triggers d'origines, les contraintes et les règles. Les éventuelles colonnes
- spécifiques de &slony1; contenant des clefs SERIAL sont supprimées.
- Enfin, le schéma &slony1; est effacé. Le nœud redevient une base de données
- indépendante. Les données ne sont pas modifiées.
- <variablelist>
- <varlistentry><term><literal>ID = ival</literal></term>
- <listitem><para>Identifiant du nœud à désinstaller.</para></listitem>
- </varlistentry>
- </variablelist>
- </para>
-
- <para>Cette commande utilise &fununinstallnode;.</para>
-
- <para>La différence entre <command>UNINSTALL NODE</command>
- et <command>DROP NODE</command> est que <command>UNINSTALL
- NODE</command> se contente de supprimer la configuration &slony1; ;
- il ne retire la configuration du nœud sur l'ensemble de réplication.
- </para>
-
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- UNINSTALL NODE ( ID = 2 );
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Lorsqu'on supprime les triggers des tables de l'application,
- cela nécessite un accès exclusif à chaque table répliquée sur le nœud
- que l'on désinstalle.</para>
- </refsect1>
- <refsect1><title>Comportement dangereux ou non-intuitif</title>
- <para>Si vous utilisez des connexions qui cachent les plans d'exécution
- (ce qui est particulièrement commun pour les frameworks applicatifs Java utilisant
- des pools de connexion), les connexions peuvent cacher des plans
- de requêtes qui se basent sur une vision pré-<command>UNINSTALL NODE</command>,
- ce qui implique que vous obtiendrez des &rmissingoids;.</para>
-
- <para>Ainsi après avoir désinstallé un nœud, il est préférable de réinitialiser
- les connexions de votre applications.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtrestartnode"><refmeta><refentrytitle>RESTART NODE</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>RESTART NODE</refname>
-
- <refpurpose>Redémarre un nœud &slony1;</refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>RESTART NODE (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para> Provoque l'arrêt et le redémarrage d'un démon
- de réplication sur le nœud spécifié.
- Théoriquement, cette commande est obsolète. En pratique,
- les délais TCP peuvent retarder les changements critiques
- de configuration jusqu'à ce qu'il soit effectué alors que le
- nœud expéditeur est en échec et doit être ignoré par les
- nœuds abonnés.
- <variablelist>
- <varlistentry><term><literal>ID = ival</literal></term>
- <listitem><para>Identifiant du nœud à redémarrer.</para></listitem>
- </varlistentry>
- </variablelist>
- </para>
-
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- RESTART NODE ( ID = 2 );
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0 ;
- Elle ne devrait plus être nécessaire à partir de la version 1.0.5.</para>
- </refsect1>
- </refentry>
-
-
- <!-- **************************************** -->
-
- <refentry id="stmtstorepath"><refmeta><refentrytitle>STORE
- PATH</refentrytitle><manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>STORE PATH</refname>
-
- <refpurpose>Configure la connexion d'un nœud &slony1;</refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>STORE PATH (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Configure la connexion d'un démon de réplication d'un nœud
- à la base de données d'un autre nœud. Si le système
- de réplication est supposé utiliser un segment spécial de réseau,
- c'est ici qu'on définit les adresses IP ou les noms d'hôtes.
- Une configuration existante peut se trouver écrasée.
- </para>
-
- <para>Le paramètre conninfo doit contenir toutes les informations
- pour se connecter à la base en tant super-utilisateur de la réplication.
- Les termes <quote>serveur</quote> et <quote>client</quote> n'ont
- rien à voir avec le rôle particulier d'un nœud dans la configuration
- d'un cluster. On peut simplement voir cela comme un
- <quote>serveur</quote> ayant un message or une donnée qu'un
- <quote>client est supposé obtenir</quote>.
- Pour une installation simple avec deux nœuds, les chemins dans les deux
- directions doivent être configurés.
- </para>
- <para>Il ne pose aucun problème de configurer un chemin entre chaque
- nœud (produit en croix complète). Les connexions ne sont établis que
- si cela est nécessaire pour transférer un événement ou une confirmation
- à cause des entrées <emphasis>listen</emphasis> ou une donnée à cause de
- <emphasis>souscriptions</emphasis>.
-
- <variablelist>
- <varlistentry><term><literal>SERVER = ival</literal></term>
- <listitem><para>Identifiant du nœud de la base à laquelle on doit se connecter.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>CLIENT = ival</literal></term>
- <listitem><para>Identifiant du nœud du démon de réplication qui se connecte.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>CONNINFO = string</literal></term>
- <listitem><para>Argument <function>PQconnectdb()</function> pour établir la connexion.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>CONNRETRY = ival</literal></term>
- <listitem><para>Nombre de secondes d'attente avant qu'un autre tentative
- de connexion soit faite dans le cas où le serveur est indisponible.
- La valeur par défaut est 10.
- </para></listitem>
- </varlistentry>
- </variablelist>
- </para>
- <para>Cette commande utilise &funstorepath;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-STORE PATH ( SERVER = 1, CLIENT = 2,
- CONNINFO = 'dbname=testdb host=serveur1 user=slony'
- );
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
-
-<!-- **************************************** -->
-
- <refentry id="stmtdroppath"><refmeta><refentrytitle>DROP PATH</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>DROP PATH</refname>
-
- <refpurpose>Supprime un chemin de connexion &slony1;</refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>DROP PATH (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Supprime les informations de connexion entre un <quote>serveur</quote> et un
- <quote>client</quote>.</para>
-
- <variablelist>
- <varlistentry><term><literal>SERVER = ival</literal></term>
- <listitem><para>Identifiant du nœud de la base à laquelle on doit se connecter.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>CLIENT = ival</literal></term>
- <listitem><para>Identifiant du nœud du démon qui se connecte.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>EVENT NODE = ival</literal></term>
-
- <listitem><para> L'identifiant du nœud utilisé pour créer l'événement de configuration
- qui annonce à tous les nœuds existants que le chemin a été supprimé.
- La valeur par défaut est l'identifiant du nœud <quote>client</quote>.
- </para></listitem>
- </varlistentry>
- </variablelist>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- DROP PATH ( SERVER = 1, CLIENT = 2 );
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
-
-<!-- **************************************** -->
-
- <refentry id="stmtstorelisten"><refmeta><refentrytitle>STORE LISTEN</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>STORE LISTEN</refname>
-
- <refpurpose>Configure un nœud &slony1; en lui indiquant où il
- doit écouter les événements</refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>STORE LISTEN (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Pour chaque entrée <quote>listen</quote>, le nœud récepteur demande
- à un nœud fournisseur de lui envoyer les événements d'un autre nœud
- ainsi que les confirmations en provenance de tous les autres nœuds existants.
- Un <quote>chemin</quote> doit exister pour
- que le récepteur (le client) puisse se connecter au fournisseur (le serveur).</para>
-
- <para>Chaque nœud du système doit écouter les événements
- de tous les autres nœuds. En règle générale, un abonné
- (voir <xref linkend="stmtsubscribeset"/>) doit écouter les événements
- d'un ensemble origine sur un fournisseur unique, qui lui envoie
- les données. En retour, l'origine de l'ensemble de réplication
- doit écouter les événements dans la direction opposée.
- Un nœud peut écouter simultanément les événements d'un même ensemble d'origine
- en provenance de différents fournisseurs. Cependant, pour traiter les
- événements <command>SYNC</command> de cet ensemble d'origine, tous les
- fournisseurs de données doivent avoir un niveau de synchronisation égal
- ou supérieur, afin d'éviter des comportements de réplication trop
- rapide.
- </para>
-
- <variablelist>
- <varlistentry><term><literal>ORIGIN = ival</literal></term>
- <listitem><para>L'identifiant du nœud d'origine que le récepteur écoute.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>PROVIDER = ival</literal></term>
- <listitem><para>L'identifiant du nœud qui envoie au récepteur les événements
- produits par le nœud origine. Si cette valeur n'est pas spécifiée,
- il s'agit du nœud origine.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>RECEIVER = ival</literal></term>
-
- <listitem><para>L'identifiant du nœud recevant les événements.</para></listitem>
- </varlistentry>
- </variablelist>
-
- <para>Cette commande utilise &funstorelisten;.</para>
- <para>Pour plus de détails, consultez &rlistenpaths;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- STORE LISTEN ( ORIGIN = 1, RECEIVER = 2, PROVIDER = 3 );
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1> <title>Note de version</title> <para>Cette commande fut introduite
- dans &slony1; 1.0. À partir de la version 1.1, vous ne <emphasis>devriez</emphasis>
- pas avoir besoin de cette commande car les voies d'écoute sont générées automatiquement.
- </para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtdroplisten"><refmeta><refentrytitle>DROP LISTEN</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>DROP LISTEN</refname>
-
- <refpurpose>Élimine la configuration qui décrit comment un nœud
- &slony1; écoute les événements
- </refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>DROP LISTEN (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Supprime une <quote>voie d'écoute</quote> de la configuration.</para>
-
- <variablelist>
- <varlistentry><term><literal>ORIGIN = ival</literal></term>
- <listitem><para>Identifiant du nœud origine que le récepteur écoute.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>PROVIDER = ival</literal></term>
- <listitem><para>Identifiant du nœud qui envoie au récepteur les événements
- produits par l'origine. Si cette valeur n'est pas spécifiée, alors il
- s'agit de l'origine.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>RECEIVER = ival</literal></term>
-
- <listitem><para>L'identifiant du nœud qui reçoit les événements.</para></listitem>
- </varlistentry>
- </variablelist>
-
- <para>Cette commande utilise &fundroplisten;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- DROP LISTEN ( ORIGIN = 1, RECEIVER = 2, PROVIDER = 3 );
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1> <title>Note de version</title> <para>Cette commande fut introduite
- dans &slony1; 1.0. À partir de la version 1.1, vous ne <emphasis>devriez</emphasis>
- pas avoir besoin de cette commande car les voies d'écoute sont générées automatiquement.
- </para>
- </refsect1>
- </refentry>
-
-
-<!-- **************************************** -->
-
-<refentry id="stmttableaddkey"><refmeta><refentrytitle>TABLE ADD KEY</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>TABLE ADD KEY</refname>
-
- <refpurpose> Ajoute une clef primaire pour
- &slony1; dans une table qui n'en possède pas
- </refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>TABLE ADD KEY (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>
- Dans un système de réplication &slony1;, chaque table répliquée
- doit avoir au moins une contrainte
- <command>UNIQUE</command> dont les colonnes sont déclarées
- <command>NOT NULL</command>. N'importe quel clef primaire
- respecte ces pré-requis.
- </para>
-
- <para>
- En dernier recours, <emphasis>dans les versions de &slony1; antérieures
- à la 2.0</emphasis>, cette commande peut être utilisée pour ajouter
- un attribut à une table qui ne possède par de clef primaire.
- Sachant que cette modification peut avoir des effets secondaires
- indésirables, <emphasis>il est très fortement recommandé que les
- utilisateurs ajoutent les attributs unique et not null par
- leurs propres moyens</emphasis>.
- </para>
-
- <para>Si vous comptez utilisez &slony1; version 2.0, vous
- <emphasis>devez</emphasis> vous débrouiller pour définir
- une clef primaire plus adéquate.
- &slony1; ne vous en fournira pas une et si vous
- avez des clefs créées via <command>TABLE ADD KEY</command>,
- ne vous attendez pas à ce que &slony1; fonctionne correctement.</para>
- <variablelist>
- <varlistentry><term><literal>NODE ID = ival</literal></term>
- <listitem><para>Identifiant du nœud de l'ensemble de réplication d'origine
- où l'on ajoute la table dans l'ensemble (voir <xref linkend="stmtsetaddtable"/>).</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>FULLY QUALIFIED NAME = 'string'</literal></term>
- <listitem><para>Le nom complet de la table composé du nom du schéma
- et du nom de la table, au format SQL suivant
- <command>quote_ident(nspname)
- || '.' || quote_ident(relname)</command>.</para></listitem>
- </varlistentry>
- </variablelist>
-
- <note><para>Pour le moment il existe des limitations; vous pouvez
- créer une table &postgres; avec aucune colonne, par exemple
- <command>create table table_vide ();</command>.
- &slony1; refusera de manipuler une telle table.
- Ce n'est pas vraiment une limitation gênante car il est
- n'est pas très intéressant de répliquer des tables qui ne contiennent
- aucune information.</para> </note>
-
- <caution><para><command>TABLE ADD KEY</command> <emphasis>ne doit
- pas être utilisée</emphasis> si vous pouvez vous en passer.
- C'est un <emphasis>élément</emphasis> des &bestpracticelink;.</para>
-
- <para>L'absence d'une clef primaire adéquate est
- une indication très sérieuse que le schéma est
- <emphasis>défectueux</emphasis>. La
- <emphasis>bonne</emphasis> méthode pour le réparer est d'introduire
- un clef primaire adéquate, et non pas de demander à &slony1; d'en <quote>bricoler</quote> une.</para>
-
- <para>Cette commande n'est <emphasis>pas</emphasis> supportée par le &logshiplink;,
- et nous n'avons pas l'intention de développer ce support.</para> </caution>
-
- <para>Cette commande utilise &funtableaddkey;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- TABLE ADD KEY ( NODE ID = 1,
- FULLY QUALIFIED NAME = 'public.history' );
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Sur le nœud origine, la commande posera un verrou exclusif
- sur la table modifiée tant que ces opérations ne seront pas terminées :
- </para>
- <itemizedlist>
- <listitem><para>Modifier la table, ajouter la colonne ;</para></listitem>
- <listitem><para>Modifier chaque ligne de la table, attacher la valeur de la séquence ;</para></listitem>
- <listitem><para>Ajouter un nouvel index unique à la table.</para></listitem>
- </itemizedlist>
-
- <para>Sur les nœuds abonnés, ces modifications sont
- réalisées sur la table lorsqu'elle est TODO, et perturbe
- pas particulièrement l'abonnement au cours du verrouillage
- sur le nœud abonné.</para>
-
- <para>Si la table est volumineuse et fréquemment mise à jour
- par vos applications, cela imposera une coupure de service
- significative qui correspond au temps de modification de la
- table sur le nœud d'origine. C'est pourquoi il est recommandé
- que cette commande ne soit pas utilisée quand c'est possible.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
-<warning> <para>Cette commande n'est <emphasis>plus supportée</emphasis>
- à partir de &slony1; version 2.0. Dans la version 2, les différentes
- <quote>modifications du catalogue</quote> réalisée sur les
- versions de &postgres; antérieures à la 8.3 sont éliminées
- afin que les exports de schéma puissent être utilisés sur n'importe
- quel nœud. Ainsi les colonnes <quote>bricolées</quote> par
- <command>TABLE ADD KEY</command> sont la chose qui empêche la commande
- <xref linkend="stmtuninstallnode"/> d'être équivalente à
- la commande SQL <command>drop schema _nom_du_cluster
- cascade;</command>.</para> </warning>
- </refsect1>
- </refentry>
-
-
-<!-- **************************************** -->
-
- <refentry id="stmtcreateset"><refmeta><refentrytitle>CREATE SET</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>CREATE SET</refname>
-
- <refpurpose>Crée un ensemble de réplication &slony1;</refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>CREATE SET (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>
- Dans le système de réplication &slony1;, les tables répliquées sont
- regroupées en ensembles. En règle générale, un ensemble contient
- des tables reliées pour une application donnée. Dans une application
- correctement conçue, toutes ces tables sont regroupées dans un
- schéma.
- </para>
- <para>
- L'ensemble de réplication est la plus petite unité qu'un nœud peut répliquer vers un autre nœud.
- Un ensemble de réplication a toujours une origine. En terme classique,
- c'est ce qu'on appelle le <quote>maître</quote>.
- Puisqu'avec &slony1; un nœud peut être simultanément <quote>maître</quote> pour un ensemble,
- et tenir le rôle d'<quote>esclave</quote> pour un autre, cette terminologie peut
- rapidement prêter à confusion et doit par conséquent être remplacée par
- <quote>ensemble d'origine</quote> et <quote>abonné</quote>.
- </para>
-
- <variablelist>
- <varlistentry><term><literal>ID = ival</literal></term>
- <listitem><para>Identifiant de l'ensemble qu'il faut créer.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>ORIGIN = ival</literal></term>
- <listitem><para>Nœud d'origine initial de cet ensemble.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>COMMENT = 'chaîne'</literal></term>
- <listitem><para>Un texte descriptif peut être ajouté pour l'ensemble de réplication.</para>
- <para>Si aucun commentaire n'est fourni, la valeur par défaut est <command>A replication set so boring no one thought to give it a name</command> (NdT : <quote>Un ensemble de réplication tellement
- ennuyeux que personne n'a pensé à lui donner un nom</quote>)
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>Cette commande utilise &funstoreset;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- CREATE SET ( ID = 1,
- ORIGIN = 1,
- COMMENT = 'Tables du système de réservation' );
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- <para>Jusqu'à la version 1.2, la commande échoue si aucun commentaire n'est fourni.</para>
- </refsect1>
- </refentry>
-
-
-<!-- **************************************** -->
-
- <refentry id="stmtdropset"><refmeta><refentrytitle>DROP SET</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>DROP SET</refname>
-
- <refpurpose>Enlever un ensemble de réplication &slony1;</refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>DROP SET (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>
- Supprime un ensemble de tables de la configuration &slony1;.
- Cette commande désabonne automatiquement tous les nœuds qui
- hébergent cet ensemble et rétablit les règles et les triggers
- originaux sur tous les abonnés.
- </para>
-
- <variablelist>
- <varlistentry><term><literal>ID = ival</literal></term>
- <listitem><para>Identifiant de l'ensemble qu'il faut supprimer.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>ORIGIN = ival</literal></term>
- <listitem><para>Nœud d'origine actuel de l'ensemble de réplication.</para></listitem>
- </varlistentry>
- </variablelist>
-
- <para>Cette commande utilise &fundropset;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- DROP SET ( ID = 5,
- ORIGIN = 2 );
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Sur chaque nœud, la commande pose un verrou exclusif sur
- chaque table répliquée afin de modifier le schéma de la table
- pour nettoyer les triggers et les règles.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtmergeset"><refmeta><refentrytitle>MERGE
- SET</refentrytitle><manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>MERGE SET</refname>
-
- <refpurpose>Fusionne plusieurs ensembles de réplication &slony1;</refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>MERGE SET (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Fusionne un ensemble de tables et de séquences dans un autre ensemble.
- Cette fonction est un contournement face à l'impossibilité
- d'ajouter des tables/séquences à des ensembles en cours de
- réplication. On peut alors créer un ensemble temporaire, y ajouter
- les nouveaux objets, abonner tous les nœuds à ce nouvel ensemble,
- puis fusionner l'ensemble courant et l'ensemble temporaire, ce qui supprime
- l'identifiant de l'ensemble temporaire.
- </para>
-
- <para>
- Cette opération ne fonctionnera si les deux ensembles ne sont pas
- répliqués <emphasis>exactement</emphasis> sur les mêmes nœuds abonnés.
- </para>
-
- <variablelist>
- <varlistentry><term><literal>ID = ival</literal></term>
- <listitem><para>Identifiant unique de l'ensemble qui contiendra les deux ensembles distincts.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>ADD ID = ival</literal></term>
- <listitem><para>Identifiant unique de l'ensemble de l'ensemble dont les objets vont être transférés.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>ORIGIN = ival</literal></term>
- <listitem><para>Nœud d'origine actuel des deux ensembles.</para></listitem>
- </varlistentry>
- </variablelist>
-
- <para>Cette commande utilise &funmergeset;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- # Supposons que l'ensemble 1 est répliqué sur les nœuds 2 et 3
- SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 2);
- SYNC (ID=1);
- WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 2, WAIT FOR=1);
- SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 3);
- SYNC (ID=1);
- WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 3, WAIT FOR=1);
- MERGE SET ( ID = 1, ADD ID = 999, ORIGIN = 1 );
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1><title>Comportement dangereux ou non-intuitif</title>
-
- <para>La fusion se déroule suivant la configuration sur le nœud origine.
- Si une fusion est demandée alors que les abonnements sont toujours
- en cours de traitement, cela peut briser les réplications en cours
- sur les nœuds abonnés car ils chercheront la configuration de cet
- ensemble alors qu'il vient d'être supprimé. Ne soyez pas trop
- rapide lorsque vous fusionnez des ensembles.
- </para>
-
- </refsect1>
- <refsect1> <title>Note de version</title> <para>Cette commande
- fut introduite dans &slony1; 1.0.5. Dans la version 1.2.1,
- une condition de concurrence (« race condition ») a été corrigée.
- Elle apparaissait lorsque la requête de fusion était soumise
- alors que les demande d'abonnement étaient traitées.
- Cela empêche les fusions avant que les abonnements ne soient
- complètement réalisés.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtsetaddtable"><refmeta><refentrytitle>SET ADD TABLE</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>SET ADD TABLE</refname>
-
- <refpurpose>Ajoute une table dans un ensemble de réplication &slony1;</refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>SET ADD TABLE (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Ajoute une table existante dans un ensemble de réplication. L'ensemble ne doit
- pas être répliqué sur un autre nœud, cette fonctionnalité est assurée par la commande
- <xref linkend="stmtmergeset"/>.
-
- <variablelist>
- <varlistentry><term><literal>SET ID = ival</literal></term>
- <listitem><para>Identifiant de l'ensemble dans lequel la table doit être ajoutée.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>ORIGIN = ival</literal></term>
- <listitem><para>Nœud origine de l'ensemble. Les prochaines versions de <application>slonik</application>
- devraient pouvoir deviner cette information.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>ID = ival</literal></term>
-
- <listitem><para>Identifiant unique de la table. Ces identifiants ne sont
- pas seulement utilisés pour désigner une table dans l'ensemble de réplication.
- Cette valeur numérique détermine également l'ordre de verrouillage des tables,
- notamment lors de la commande <xref linkend="stmtlockset"/>.
- Cet identifiant doit donc suivre une certaine hiérarchie afin que les scripts
- <application>slonik</application> ne provoquent de situation d'inter-blocage (« deadlocks »).
- </para>
-
- <para>Cet identifiant doit être unique pour tous les ensembles de réplication ;
- vous ne devez pas avoir deux tables du même cluster avec le même identifiant.
- </para></listitem>
- </varlistentry>
- <varlistentry><term><literal>FULLY QUALIFIED NAME = 'string'</literal></term>
- <listitem><para>Le nom complet de la table tel que décrit dans
- <xref linkend="stmttableaddkey"/>.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>KEY = { 'string' | SERIAL }</literal></term> <listitem><para>
- <emphasis>(Facultatif)</emphasis> Le nom de l'index relatif à la colonne unique et
- NOT NULL qui est utilisée comme identifiant de ligne lors de la réplication.
- Si le mot-clef SERIAL est utilisé, cela indique qu'il faut utiliser la colonne
- spéciale ajoutée avec la commande <xref linkend="stmttableaddkey"/>.
- Par défaut, on utilise la clef primaire de la table. Le nom de l'index n'est
- <emphasis>pas</emphasis> un nom complet ; vous devez omettre le schéma.</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>COMMENT = 'string'</literal></term>
- <listitem><para>Un texte décrivant la table.</para></listitem>
- </varlistentry>
- </variablelist>
- </para>
- <para>Cette commande utilise &funsetaddtable;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-SET ADD TABLE (
- SET ID = 1,
- ORIGIN = 1,
- ID = 20,
- FULLY QUALIFIED NAME = 'public.tracker_ticket',
- COMMENT = 'Ticket de Support'
-);
- </programlisting>
- </refsect1>
- <refsect1> <title>Messages d'erreur</title>
-
- <para>Voici quelque messages d'erreurs que vous rencontrerez en cas d'utilisation incorrecte :</para>
-
- <variablelist>
- <varlistentry><term><literal>Slony-I: setAddTable_int: table public.ma_table PK column id nullable</literal></term>
-
- <listitem><para>Les clefs primaires (ou les clefs candidates) doivent être composées
- de colonnes <command>NOT NULL</command>. Si vous avez une clef primaire candidate dont une
- colonne n'est pas déclarée ainsi, alors &slony1; rejettera la table et produira ce message.</para>
- </listitem> </varlistentry>
-
- <varlistentry><term><literal>Slony-I: setAddTable_int: table id 14 has already been assigned!</literal></term>
-
- <listitem><para>L'identifiant de la table, stocké dans
- <envar>sl_table.tab_id</envar>, doit être unique pour tous les nœuds/tables/ensembles.
- Ce message indique que vous avez tenté de déclarer un identifiant qui est déjà utilisé.
- </para> </listitem> </varlistentry>
-
- <varlistentry><term><literal>Slony-I: setAddTable_int(): table public.ma_table has no index mt_idx_14</literal></term>
-
- <listitem><para>Ceci se produit en général avec les clefs primaires candidates ;
- le message indique que l'index spécifié n'est pas disponible sur ce nœud.
- </para> </listitem> </varlistentry>
-
- <varlistentry><term><literal>Slony-I: setAddTable_int(): table public.ma_table not found</literal></term>
-
- <listitem><para>Pire que l'absence d'un index, c'est la table qui est manquante.
- Le message indique que le processus que vous avez utilisé pour mettre en place le schéma n'a pas
- fonctionné correctement.</para>
- </listitem> </varlistentry>
-
- <varlistentry><term><literal>Slony-I: setAddTable_int(): public.ma_vue is not a regular table</literal></term>
-
- <listitem><para>Vous ne pouvez répliquer que des tables (en tout cas avec
- <command>SET ADD TABLE</command>). Cela n'inclut pas les vues et les index
- (les index sont répliqués de facto, mais on peut pas demander explicitement la réplication d'un index).
- </para> </listitem> </varlistentry>
-
- <varlistentry><term><literal>Slony-I: setAddTable_int(): set 4 not found</literal></term>
-
- <listitem><para>Vous devez défini l'ensemble de réplication avant de lui assigner des tables.
- </para> </listitem> </varlistentry>
-
- <varlistentry><term><literal>Slony-I: setAddTable(): set 4 has remote origin</literal></term>
-
- <listitem><para>Ceci se produit lorsque l'ensemble de réplication #4 est configuré
- sur une origine, le nœud 1, et que vous lancez une commande <command>SET ADD
- TABLE</command> qui spécifie un autre nœud que le nœud 1. Ceci se produit généralement
- lorsque la configuration <command>admin conninfo</command> est confuse à l'intérieur du
- préambule du script slonik...</para>
- </listitem>
- </varlistentry>
-
- <varlistentry><term><literal>Slony-I: cannot add table to currently subscribed set 1</literal></term>
-
- <listitem><para>&slony1; ne peut pas ajouter des tables dans un ensemble qui est
- en cours de réplication. Pour contourner ce problème, vous devez définir un nouvel ensemble
- qui contiendra les nouvelles tables.</para> </listitem> </varlistentry>
-
- </variablelist>
-
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Sur le nœud origine, cette opération demande un verrou exclusif très bref sur la table
- afin de lui ajouter les triggers de réplication. Sur les nœuds abonnés, les verrous
- correspondant sont réalisés au moment de l'événement <command>SUBSCRIBE_SET</command>.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtsetaddsequence"><refmeta><refentrytitle>SET ADD SEQUENCE</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>SET ADD SEQUENCE</refname>
-
- <refpurpose>Ajoute une séquence dans un ensemble de réplication</refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>SET ADD SEQUENCE (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
-<refsect1>
- <title>Description</title>
-
- <para>
- Ajoute une séquence existante dans un ensemble de réplication. L'ensemble ne
- doit pas être répliqué sur un autre nœud. Cette fonctionnalité est supportée
- par la commande <xref linkend="stmtmergeset"/>.
-
- <variablelist>
- <varlistentry><term><literal>SET ID = ival</literal></term>
- <listitem><para>Identifiant de l'ensemble dans lequel on ajoute la séquence.
- </para></listitem>
- </varlistentry>
- <varlistentry><term><literal>ORIGIN = ival</literal></term>
- <listitem><para>Nœud d'origine de l'ensemble. Les prochaines version de <application>slonik</application>
- devraient pouvoir deviner cette information.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>ID = ival</literal></term>
-
- <listitem><para>Identifiant unique de la séquence.
- <note><para> Notons
- que cet identifiant doit être unique parmi <emphasis>toutes les séquences</emphasis>
- du cluster ; la numérotation des tables est indépendante, donc il est possible
- de donner l'identifiant 20 à une table et à une séquence, sans que cela ne crée de confusion.
- </para> </note></para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>FULLY QUALIFIED NAME = 'string'</literal></term>
- <listitem><para>Le nom complet de la séquence telle que décrit dans
- <xref linkend="stmttableaddkey"/>.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>COMMENT = 'string'</literal></term>
- <listitem><para>Un texte décrivant la séquence.</para></listitem>
- </varlistentry>
- </variablelist>
- </para>
- <para>Cette commande utilise la fonction &funsetaddsequence;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- SET ADD SEQUENCE (
- SET ID = 1,
- ORIGIN = 1,
- ID = 20,
- FULLY QUALIFIED NAME = 'public.tracker_ticket_id_seq',
- COMMENT = 'Séquence d'identifiants des tickets de support'
- );
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtsetdroptable"><refmeta><refentrytitle>SET DROP TABLE</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>SET DROP TABLE</refname>
-
- <refpurpose>Supprime une table d'un ensemble de réplication &slony1;
- </refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>SET DROP TABLE (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>
- Supprime une table d'un ensemble de réplication.
- </para>
- <para>
- Notez que cette action ne supprimera <emphasis>pas</emphasis> une clef primaire
- candidate créée avec la commande <xref linkend="stmttableaddkey"/>.
-
- <variablelist>
- <varlistentry><term><literal>ORIGIN = ival</literal></term>
- <listitem><para>Nœud d'origine de l'ensemble de réplication.
- Les prochaines versions de <application>slonik</application>
- devraient pouvoir deviner cette information.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>ID = ival</literal></term>
-
- <listitem><para>Identifiant unique de la table.</para></listitem></varlistentry>
- </variablelist>
- </para>
- <para>Cette commande utilise la fonction &funsetdroptable;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- SET DROP TABLE (
- ORIGIN = 1,
- ID = 20
- );
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Cette opération pose un verrou exclusif sur la table qui est supprimée afin
- de retirer les triggers de réplication. Sur les nœuds abonnées, cela implique également
- le rétablissement des règles et des triggers qui ont été désactivés.
- </para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.5.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtsetdropsequence"><refmeta><refentrytitle>SET DROP SEQUENCE</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>SET DROP SEQUENCE</refname>
-
- <refpurpose>Supprime une séquence d'un ensemble de réplication &slony1;
- </refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>SET DROP SEQUENCE (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>
- Supprime une séquence existante dans un ensemble de réplication.
- <variablelist>
- <varlistentry><term><literal>ORIGIN = ival</literal></term>
- <listitem><para>Nœud d'origine de l'ensemble. Les prochaines versions de <application>slonik</application>
- devraient pouvoir deviner cette information.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>ID = ival</literal></term>
-
- <listitem><para>Identifiant unique de la séquence.</para></listitem>
-
- </varlistentry>
- </variablelist>
- </para>
- <para>Cette commande utilise la fonction &funsetdropsequence;.</para>
- </refsect1>
-<refsect1><title>Exemple</title>
- <programlisting>
- SET DROP SEQUENCE (
- ORIGIN = 1,
- ID = 20,
- );
-</programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.5.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtsetmovetable"><refmeta><refentrytitle>SET MOVE
- TABLE</refentrytitle><manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>SET MOVE TABLE</refname>
-
- <refpurpose>Déplace une table d'un ensemble de réplication vers un autre.
- </refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>SET MOVE TABLE (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>
- Change l'ensemble de réplication dans lequel se trouve la table. L'ensemble courant et le
- nouveau doivent avoir le même nœud origine et les même nœuds abonnés.
-
- <caution><para>La méthode d'abonnement d'un nouvel ensemble de réplication est
- particulière.Vous devez vous assurer que l'abonnement est complètement effectué sur tous les nœuds
- avant de déplacer les tables. Déplacer une table trop tôt vers un nouvel ensemble
- implique que le nœud abonné va essayer d'ajouter la table pendant le processus d'abonnement
- de l'ensemble de réplication, ce qui échoue suite à une erreur de clef dupliquée et provoque
- l'arrêt de la réplication.</para></caution>
-
- <variablelist>
- <varlistentry><term><literal>ORIGIN = ival</literal></term>
- <listitem><para>Origine actuelle de l'ensemble. Les prochaines versions de <application>slonik</application>
- devraient pouvoir deviner cette information.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>ID = ival</literal></term>
-
- <listitem><para>Identifiant unique de la table.</para></listitem></varlistentry>
- <varlistentry><term><literal>NEW SET = ival</literal></term>
-
- <listitem><para>Identifiant unique de l'ensemble dans lequel il faut ajouter la table.</para></listitem></varlistentry>
- </variablelist>
- </para>
- <para>Cette commande utilise la fonction &funsetmovetable;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-SET MOVE TABLE (
- ORIGIN = 1,
- ID = 20,
- NEW SET = 3
-);
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.5.</para>
- </refsect1>
-</refentry>
-
-
-<!-- **************************************** -->
-
- <refentry id="stmtsetmovesequence"><refmeta><refentrytitle>SET MOVE SEQUENCE</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>SET MOVE SEQUENCE</refname>
-
- <refpurpose>Déplace une séquence d'un ensemble de réplication &slony1; vers un autre.
- </refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>SET MOVE SEQUENCE (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>
- Change l'ensemble de réplication dans lequel se trouve la séquence.
- L'ensemble courant et le nouveau doivent avoir le même nœud d'origine
- et les mêmes nœuds abonnés.
-
- <caution><para>La méthode d'abonnement à un nouvel ensemble est particulière.
- Vous devez vous assurer que l'abonnement est complètement effectué
- avant de déplacer les séquences. Déplacer une séquence top tôt peut impliquer
- une tentative d'ajout de la séquence pendant le processus d'abonnement,
- ce qui échouera en émettant une erreur à cause d'une clef dupliquée et
- provoquera l'arrêt de la réplication.</para></caution>
-
- <variablelist>
- <varlistentry><term><literal>ORIGIN = ival</literal></term>
- <listitem><para>Nœud d'origine de l'ensemble de réplication. Les
- futures versions de <application>slonik</application> devraient
- deviner toutes seules cette information.</para></listitem>
- </varlistentry>
- <varlistentry><term><literal>ID = ival</literal></term>
-
- <listitem><para>Identifiant unique de la séquence.</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>NEW SET = ival</literal></term>
-
- <listitem><para>Identifiant unique de l'ensemble de réplication dans lequel
- la séquence doit être déplacée.</para></listitem>
-
- </varlistentry>
- </variablelist>
- </para>
- <para>Cette commande utilise &funsetmovesequence;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-SET MOVE SEQUENCE (
- ORIGIN = 1,
- ID = 20,
- NEW SET = 3
-);
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.5.</para>
- </refsect1>
- </refentry>
-
-
-<!-- **************************************** -->
-
- <refentry id="stmtstoretrigger"><refmeta><refentrytitle>STORE TRIGGER</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>STORE TRIGGER</refname>
-
- <refpurpose>Indique qu'un trigger ne doit pas être désactivé par &slony1;
-sur un nœud abonné.
- </refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>STORE TRIGGER (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Par défaut, tous les triggers définis par l'utilisateur sont
-désactivés sur tout les nœuds abonnés lorsque la table est répliquée.
-Cette commande peut être utilisée pour empêcher explicitement la désactivation
-d'un trigger.
- <variablelist>
- <varlistentry><term><literal>TABLE ID = ival</literal></term>
- <listitem><para> L'identifiant numérique et unique de la table concernée par le trigger.</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>TRIGGER NAME = 'string'</literal></term>
-
- <listitem><para>Le nom du trigger tel qu'on le trouve dans le catalogue système
- <envar>pg_trigger</envar>.</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>EVENT NODE = ival</literal></term>
-
- <listitem><para>(Optionnel) L'identifiant du nœud utilisé pour
-créer l'événement de configuration qui annonce aux nœuds existants la
-présence d'un trigger spécial. Par défaut, cette valeur est 1.
- </para></listitem>
-
- </varlistentry>
- </variablelist>
- </para>
- <note><para>Une astuce consiste à lancer <command>STORE
- TRIGGER</command> <emphasis>avant que le trigger ne soit installé
- </emphasis>, ce qui ne provoquera pas d'erreurs. Vous pouvez
- ainsi définir la gestion d'un trigger par &slony1;
- <emphasis>avant</emphasis> qu'il ne soit installé. Vous êtes alors
- certain que le trigger est actif sur tous les nœuds immédiatement
- après son installation via <xref linkend="stmtddlscript"/> ; il n'y a
- aucun risque de voir un événement passer entre les événements
- <command>EXECUTE SCRIPT</command> et <command>STORE TRIGGER</command>.
- </para>
- </note>
- <para>Cette commande utilise &funstoretrigger;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-STORE TRIGGER (
- TABLE ID = 2,
- TRIGGER NAME = 'cache_invalidation'
-);
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Cette opération pose brièvement un verrou exclusif sur la table spécifiée
-sur chaque nœud auquel elle s'applique, afin de modifier le schéma de la table
-et y ajouter de nouveau le trigger.
- </para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
-
- <para>Avec &slony1; version 2.0, cette commande est supprimée car
-obsolète. En effet, les triggers ne sont plus <quote>trafiqués</quote>
-dans le catalogue système.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtdroptrigger"><refmeta><refentrytitle>DROP TRIGGER</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>DROP TRIGGER</refname>
-
- <refpurpose>Cette commande redonne à un trigger son comportement par défaut :
-c'est-à-dire qu'il ne se déclenche pas sur les nœuds abonnés.</refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>DROP TRIGGER (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Supprime la gestion particulière du trigger spécifié.
- <variablelist>
- <varlistentry>
- <term><literal>TABLE ID = ival</literal></term>
- <listitem>
- <para>L'identifiant numérique et unique de la table pour laquelle le
- trigger est défini.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><literal>TRIGGER NAME = 'string'</literal></term>
- <listitem><para>Le nom du trigger tel qu'on le trouve dans le catalogue système
- <envar>pg_trigger</envar>.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><literal>EVENT NODE = ival</literal></term>
- <listitem>
- <para>(Optionnel) L'identifiant du nœud utilisé pour
- créer l'événement de configuration qui annonce aux nœuds existants la
- présence d'un trigger spécial. Par défaut, cette valeur est 1.</para>
- </listitem>
- </varlistentry>
- </variablelist>
- </para>
- <para>Cette commande utilise &fundroptrigger;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-DROP TRIGGER (
- TABLE ID = 2,
- TRIGGER NAME = 'cache_invalidation'
-);
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Cette opération pose brièvement un verrou exclusif sur la table spécifiée
-sur chaque nœud auquel elle s'applique, afin de modifier le schéma de la table
-et y ajouter de nouveau le trigger.
- </para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
-
- <para>Avec &slony1; version 2.0, cette commande est supprimée car
-obsolète. En effet, les triggers ne sont plus <quote>trafiqués</quote>
-dans le catalogue système.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
- <refentry id="stmtsubscribeset"><refmeta><refentrytitle>SUBSCRIBE SET</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>SUBSCRIBE SET</refname>
-
- <refpurpose>Lance la réplication d'un ensemble donné</refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>SUBSCRIBE SET (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Cette commande réalise une des deux opérations suivantes :</para>
-
- <itemizedlist>
-
- <listitem><para>Initie la réplication pour un ensemble de réplication.</para>
- <para>Ceci déclenche la réplication sur un nœud (abonné) soit à partir
-de l'origine soit à partir du fournisseur, qui doit être lui-même un nœud
-abonné actif et transmetteur (« forwarding subscriber »).</para>
-
- <para>Les tables de l'application contenues dans l'ensemble de réplication
-doivent déjà exister et, idéalement, elles sont vides. La version courante de
-&slony1; ne tente <emphasis>pas</emphasis> de copier le schéma de l'ensemble
-de réplication. Le démon de réplication démarre et commence à copier le contenu
-de l'ensemble de réplication à partir du fournisseur spécifié, puis essaie
-de rattraper son retard en rejouant les mises à jour qui se sont produites
-lors du processus de copie. Un fois que l'abonnement a réussi, les tables
-sont protégées avec des triggers contre les mises à jour en provenance de
-l'application.
- </para>
-
- <para>Si les tables sur l'abonné ne sont
- <emphasis>pas</emphasis> vides, alors l'événement <command>COPY
- SET</command> (qui fait partie du processus d'abonnement)
- devra effectuer quelques taches supplémentaires :</para>
- <itemizedlist>
-
- <listitem><para>Il tente d'effectuer une <command>TRUNCATE</command>
- sur la table, ce qui devrait être efficace.</para> </listitem>
-
- <listitem><para>Si cela ne fonctionne pas (une relation sur une
-clef étrangère empêche peut-être le fonctionnement de TRUNCATE), il
-utilise la commande <command>DELETE</command> pour effacer toutes les
-<quote>anciennes</quote>
-entrées de la table.</para></listitem>
-
- <listitem><para>Ces anciennes données encombrent encore l'espace
-disque jusqu'à ce qu'un <command>VACUUM</command> soit effectué <emphasis>après</emphasis>
-la fin du processus d'abonnement.</para></listitem>
-
- <listitem><para>Les index de la table contiendront des références
-aux anciennes données, ce qui ralentira l'insertion de nouvelles données
-dans les index.</para></listitem>
- </itemizedlist>
-
- <warning><para>Le temps d'exécution de cette opération n'est pas
-négligeable. Si vous avez un grand volume de données dans un ensemble
-particulier de tables, cela peut prendre plusieurs heures, voire plusieurs
-jours pour que l'opération aboutisse (ici <quote>un grand volume</quote>
-signifie <quote>des dizaines ou des centaines de gigaoctets de données</quote>).</para>
-
- <para>Cependant, la requête <command>SUBSCRIBE SET</command> se terminera
-presque immédiatement, même si les travaux, gérés par l'événement
-<command>COPY SET</command>, sont encore en cours. Si vous devez configurer
-les abonnements sur des nœuds en cascade, vous devez attendre que chaque
-abonné ait terminé son abonnement avant de soumettre des requête d'abonnement
-qui utilisent ce nœud comme fournisseur. Si vous ne le faites pas, ce n'est pas
-très grave : <command>slonik</command> va vérifier le nœud, découvrir qu'il
-n'est pas encore un fournisseur actif et reporter l'erreur suivante :
-</para>
-
-<programlisting>
- Slony-I: provider 2 is not an active forwarding node for replication set 1
-</programlisting>
-
- <para>En pratique, de telles requêtes d'abonnement seront ignorées
-jusqu'à ce que le fournisseur soit prêt.</para>
-</warning>
-
- </listitem>
-
- <listitem><para>Modifier les informations d'abonnement pour les
-nœuds qui sont déjà abonnés.</para>
-
- <para>Si vous devez modifier les informations d'abonnement pour un
-nœud donné, vous devez <emphasis>également</emphasis> soumettre les
-nouvelles informations avec cette commande, et la nouvelle configuration sera
-propagée à travers le réseau de réplication. En général, on modifie
-les informations d'abonnement lorsqu'on veut abonner un nœud à un fournisseur
-<emphasis>différent</emphasis> ou transformer un nœud en <quote>transmetteur</quote>
-afin qu'il puisse à son tour devenir le fournisseur d'un autre abonné.
-</para>
-
- </listitem>
- </itemizedlist>
-
- <variablelist>
- <varlistentry><term><literal>ID = ival</literal></term>
- <listitem><para>Identifiant de l'ensemble auquel on s'abonne</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>PROVIDER = ival</literal></term>
-
- <listitem><para>Identifiant du nœud fournisseur qui transmet les données
-à ce nœud</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>RECEIVER = ival</literal></term>
-
- <listitem><para>Identifiant du nouveau nœud abonné</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>FORWARD = boolean</literal></term>
-
- <listitem><para>Indique si le nouvel abonné doit stocker les logs
-pendant la réplication afin de pouvoir devenir fournisseur pour de futurs
-nœuds.</para></listitem>
-
- </varlistentry>
- </variablelist>
- <para>Cette commande utilise &funsubscribeset;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-SUBSCRIBE SET (
- ID = 1,
- PROVIDER = 1,
- RECEIVER = 3,
- FORWARD = YES
-);
- </programlisting>
- </refsect1>
-
- <refsect1> <title>Transmission</title>
-
- <para>Le paramètre <command>FORWARD=boolean</command> indique si le
-l'abonné doit conserver les informations dans les tables &sllog1; et &sllog2;.
-Ceci implique plusieurs choses...</para>
-
- <para>Stocker les données dans ces tables sur l'abonné représente
-une charge supplémentaire. Si vous êtes certain(e) que vous n'effectuerez
-jamais les opérations <xref linkend="stmtmoveset"/> ou <xref
-linkend="stmtfailover"/> sur un abonné particulier, il vaut mieux
-désactiver la transmission sur ce nœud.</para>
-
- <para>Cela étant dit, dans certains cas, le fait de désactiver cette option
-peut poser des problèmes lorsqu'on se trouve dans une situation inattendue.
-De manière empirique, on considère qu'il est préférable que <emphasis>tout
-nœud connecté directement à l'origine</emphasis> soit
-un <quote>nœud transmetteur </quote>. Il est possible que ce nœud
-soit perdu lors d'une bascule d'urgence. Le problème survient lorsque
-ce nœud est en avance sur les autres nœuds.</para>
-
- <para>Supposons que l'origine, le nœud 1, est au numéro de SYNC
-88901, un nœud non-transmetteur, le nœud 2 en est arrivé au numéro
-88897, tandis que les autres nœuds transmetteur, 3, 4, et 5, en sont
-seulement au SYNC numéro 88895. À ce moment, le disque système sur le
-nœud origine prend feu. Le nœud 2 possède les <emphasis>données</emphasis> à jour
-jusqu'à 88901, mais aucun nœud transmetteur ne dispose, dans les tables
-&sllog1; ou &sllog2;, des données correspondant
-aux événements SYNCs numérotés 88896 et 88897. Il n'y a donc
-aucun moyen de ramener les nœuds 3-5 à ce niveau.</para>
-
- <para>À ce stade, vous avez deux choix : supprimer le nœud2 car il
-n'existe aucun moyen de le maintenir, ou supprimer tous les nœuds
-<emphasis>sauf</emphasis> le nœud 2, car il n'existe aucun moyen de les
-amener jusqu'à l'événement SYNC 88897.</para>
-
- <para>Ce dilemme peut être évité en s'assurant que tous les nœuds directement
-abonnés à l'origine sont des transmetteurs.</para>
-
- </refsect1>
- <refsect1> <title>Comportement dangereux et non-intuitif</title>
-
- <itemizedlist>
-
- <listitem><para>Le fait que la requête se termine immédiatement
-même si l'abonnement prend un temps considérable est parfois surprenant.
- </para>
-
- <para>Le traitement des abonnements implique
- <emphasis>deux</emphasis> événements ; l'opération
- <command>SUBSCRIBE_SET</command>, initié sur le nœud fournisseur,
-et une opération <command>ENABLE_SUBSCRIPTION</command>, qui est
-initiée sur le nœud abonné. Cela signifie que <xref
- linkend="stmtwaitevent"/> ne peut pas attendre la fin d'une souscription.
-Si vous souhaitez attendre la fin d'un abonnement, alors vous devez soumettre une
-requête <xref linkend="stmtsync"/> et attendre que <emphasis>cet</emphasis> événement
-s'achève.</para>
- </listitem>
-
- <listitem><para> Cette commande a <emphasis>deux</emphasis>
-objectifs : mettre en place des abonnements (ce qui n'est très surprenant)
-et <emphasis>modifier des abonnements</emphasis>, ce qui n'est pas forcément
-intuitif.</para> </listitem>
-
- <listitem><para>Les nouveaux abonnements sont définis en utilisant
-<command>DELETE</command> ou <command>TRUNCATE</command> pour vider
-les tables sur l'abonné. Si vous avez créé un nouveau nœud en
-recopiant les données à partir d'un nœud existant, il peut <quote>paraître
-évident</quote> que ces données seront conservées. Ce n'est pas le cas,
-l'ancien contenu est détruit et le nœud est re-peupler <emphasis>à partir
-de zéro</emphasis>.</para> </listitem>
-
- </itemizedlist>
-
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Cette opération ne nécessite <emphasis>pas</emphasis> de verrous
-sur le nœud fournisseur.</para>
-
- <para>Sur le nœud abonné, l'opération placera un verrou
-sur toutes les table de l'ensemble de réplication. Dans la version
-1.2, les verrous exclusifs sont placés au début du processus ; dans les
-versions antérieures, les verrous sont placés implicitement uniquement lorsque
-qu'une activité le demande, ce qui laisse une possibilité d'inter-blocage
-(« deadlock ») si d'autres applications peuvent accéder à la base à ce moment-là.
- </para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtunsubscribeset"><refmeta><refentrytitle>UNSUBSCRIBE SET</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>UNSUBSCRIBE SET</refname>
-
- <refpurpose>Arrête la réplication d'un ensemble de réplication &slony1;</refpurpose></refnamediv>
-
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>UNSUBSCRIBE SET (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Cette commande interrompt la réplication d'un ensemble sur un abonné.
-Les tables sont alors ouvertes en accès total aux applications clientes sur l'ancien
-abonné. Les tables ne sont ni détruites ni modifiées. Tous les triggers originaux, les règles
-et les contraintes sont restaurées.
-
- <variablelist>
- <varlistentry><term><literal> ID = ival</literal></term>
- <listitem><para>Identifiant de l'ensemble à désabonner</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>RECEIVER = ival</literal></term>
-
- <listitem><para>Identifiant du nœud de l' (ancien) abonné</para></listitem>
-
- </varlistentry>
- </variablelist>
- </para>
- <para>Cette commande utilise &fununsubscribeset;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-UNSUBSCRIBE SET (
- ID = 1,
- RECEIVER = 3
-);
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Des verrous exclusifs sont posés sur chaque table répliquée
-de l'abonné afin de supprimer les triggers de réplication et de restaurer
-les anciens triggers/règles.</para>
- </refsect1>
-
- <refsect1><title>Comportement dangereux et non-intuitif</title>
-
- <para>Ré-abonner un ensemble désabonné nécessite une
- <emphasis>copie fraîche et complète</emphasis> des données obtenue à partir
-du nœud fournisseur car les tables ont pu être soumises à des modifications
-indépendantes.</para>
-
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
-
-<!-- **************************************** -->
-
- <refentry id ="stmtlockset"><refmeta><refentrytitle>LOCK SET</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>LOCK SET</refname>
-
- <refpurpose>Protège un ensemble de réplication &slony1; pour le
-préparer à un <command>MOVE SET</command></refpurpose></refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>LOCK SET (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Cette commande protège un ensemble de réplication des mises à
-jour en provenance des applications clientes, en préparation d'une
-commande <xref linkend="stmtmoveset"/>.
- </para>
-
- <para>Cette commande doit être la première dans un groupe de commande <command>try</command>.
-En effet, il faut <quote>committer</quote> les changements faits sur les tables
- (ajout d'une fonction trigger spéciale) avant d'attendre que toutes les
-transactions concurrentes se termine. En même temps, il ne faut pas
-non plus garder une transaction ouverte sur la base elle-même car cela
-cela signifierait qu'elle se bloque elle-même.
- </para>
-
- <para>Notons qu'il s'agit d'une opération &rlocking;, ce qui signifie qu'elle peut être
-bloqué derrière d'autres activités de la base.</para>
-
- <para>L'opération attend que les identifiants de transaction avancent
-afin qu'aucune donnée ne soit oubliée sur la nouvelle origine. Ainsi,
-si vous avez des transactions très longues en cours sur le nœud source,
-cette opération attendra que ces transactions aboutissent.
-Malheureusement, si vous avez une autre base de données sur le même
- postmaster du nœud origine, les transactions longues en cours
-sur cette base seront aussi prises en compte même si elles sont par définition
-indépendantes.
-
- <variablelist>
- <varlistentry><term><literal>ID = ival</literal></term>
- <listitem><para>Identifiant de l'ensemble à bloquer</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>ORIGIN = ival</literal></term>
-
- <listitem><para>Identifiant du nœud de l'ensemble d'origine</para></listitem>
-
- </varlistentry>
- </variablelist>
- </para>
- <para>Cette commande utilise &funlockset;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-LOCK SET (
- ID = 1,
- ORIGIN = 3
-);
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Des verrous exclusifs sont posés sur chaque table répliquée sur le nœud origine
- et des triggers qui rejettent les mises à jour sont ajoutés su chacune de ces tables.
- </para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtunlockset"><refmeta><refentrytitle>UNLOCK SET</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>UNLOCK SET</refname>
-
- <refpurpose>Déverrouille un ensemble &slony1; qui est bloqué</refpurpose></refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>UNLOCK SET (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>
- Cette commande déverrouille un ensemble préalablement verrouillé.
-
- <variablelist>
- <varlistentry><term><literal>ID = ival</literal></term>
- <listitem><para>Identifiant de l'ensemble à déverrouiller</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>ORIGIN = ival</literal></term>
-
- <listitem><para>Identifiant du nœud origine de l'ensemble</para></listitem>
-
- </varlistentry>
- </variablelist>
- </para>
- <para>Cette commande utilise &fununlockset;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-UNLOCK SET (
- ID = 1,
- ORIGIN = 3
-);
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Des verrous exclusifs sont placés sur chaque table répliquée sur le nœud origine
- car les triggers qui rejetent les mises à jour sont retirés de chacune des tables.
- </para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
-
-<!-- **************************************** -->
-
- <refentry id="stmtmoveset"><refmeta><refentrytitle>MOVE SET</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>MOVE SET</refname>
-
- <refpurpose>Change l'origine d'un ensemble de réplication &slony1;
- </refpurpose></refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>MOVE SET (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Cette commande déplace l'origine d'un ensemble de réplication d'un nœud
- vers un autre. La nouvelle origine doit être un abonné de cet ensemble. L'ensemble
- doit être verrouillé sur l'ancien nœud origine.
- </para>
-
- <para>Après cette commande, l'ensemble ne peut plus être déverrouillé sur
- l'ancienne origine. Celle-ci va continuer comme un nœud transmetteur
- de l'ensemble et la chaîne d'abonnement entre l'ancienne et la nouvelle origine
- sera inversée. Dès que la nouvelle origine a terminé le traitement de l'événement
- (ce qui inclue tous les événements SYNC qui se sont produit avant la commande),
- elle prend le contrôle et ouvre toutes les tables de l'ensemble de réplication
- aux mises à jour en provenance de l'application.
- </para>
-
- <para>Ceci n'est <emphasis>pas</emphasis> une bascule d'urgence car cela nécessite
- que l'ancienne origine fonctionne correctement (vous devez verrouiller l'ensemble
- de réplication sur l'ancienne origine). Il est préférable d'utiliser
- <command>MOVE SET</command> au lieu de <command>FAILOVER</command> si c'est possible
- car la commande <command>FAILOVER</command> transforme le nœud origine en un
- nœud corrompu. Avant d'effectuer un <command>MOVE SET</command>, il faut lancer la
- commande <command>LOCK SET</command>.
-</para>
-
- <para>Notez qu'il s'agit d'une opération &rlocking;, ce qui signifie qu'elle peut être bloquée
- derrière l'activité des autres bases.
-
- <variablelist>
- <varlistentry><term><literal>ID = ival</literal></term>
- <listitem><para>Identifiant de l'ensemble à transférer</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>OLD ORIGIN = ival</literal></term>
-
- <listitem><para>Identifiant du nœud origine actuel</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>NEW ORIGIN = ival</literal></term>
-
- <listitem><para>Identifiant du futur nœud origine</para></listitem>
-
- </varlistentry>
- </variablelist>
- </para>
- <para>Cette commande utilise &funmoveset;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-LOCK SET (
- ID = 1,
- ORIGIN = 1
-);
-MOVE SET (
- ID = 1,
- OLD ORIGIN = 1,
- NEW ORIGIN = 3
-);
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Des verrous exclusifs sont posés sur chaque table répliquée,
-à la fois sur l'ancien nœud origine et le nouveau nœud origine, car
-les triggers de réplication sont changés sur les deux nœuds :
-sur l'ancienne origine, chaque table supprime deux triggers
-(logtrigger et lockset) et ajoute un trigger denyaccess ;
-sur la nouvelle origine, le trigger denyaccess est supprimé et
-le trigger logtrigger est ajouté.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtfailover"><refmeta><refentrytitle>FAILOVER</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>FAILOVER</refname>
-
- <refpurpose>Cette commande bascule un ensemble de réplication
-en échec vers un nœud de secours.
- </refpurpose></refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>FAILOVER (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>
- La commande <command>FAILOVER</command> transfert tous les ensembles dont
-l'origine est en panne vers le nœud de secours.
- <application>slonik</application> va contacter tous les autres nœuds directement
-abonnés au nœud en panne pour déterminer le nœud qui a le meilleur niveau de synchronisation
-pour chacun des ensembles de réplication. Si un autre nœud a un niveau de synchronisation
-plus élevé que le nœud de secours, la réplication sera d'abord redirigée pour que le nœud
-de secours rattrape son retard sur l'autre nœud, puis pour qu'il assume le rôle d'origine
-et reçoive les mises à jour.
- </para>
-
- <para>
- Après une bascule d'urgence réussie, tous les anciens nœuds abonnés directement
-au nœud en panne deviennent des abonnés direct du nœud de secours.
-Le nœud en panne est abandonné et doit être retiré de la configuration avec
-<xref linkend="stmtdropnode"/>.
- </para>
-
- <variablelist>
- <varlistentry><term><literal>ID = ival</literal></term>
- <listitem><para>Identifiant du nœud en panne</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>BACKUP NODE = ival</literal></term>
-
- <listitem><para>Identifiant du nœud de secours qui va prendre en charge
-les ensembles de réplication dont l'origine est le nœud en panne</para></listitem>
-
- </varlistentry>
- </variablelist>
-
- <para>Cette commande utilise &funfailednode;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-FAILOVER (
- ID = 1,
- BACKUP NODE = 2
-);
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Des verrous exclusifs sont posés sur chaque table répliquée sur
-le nouveau nœud origine car les triggers de réplication sont changés.
-Si la nouvelle origine n'est pas tout à fait à jour et que des données
-doivent être rapatriées depuis à partir d'un autre nœud qui est mieux synchronisé,
-alors la nouvelle origine ne sera pas utilisable avant que ces mises à jour
-soient terminées.
- </para>
- </refsect1>
- <refsect1><title>Comportement dangereux et non-intuitif</title>
- <para>Cette commande va abandonner le nœud en panne.
-Il n'y a pas de possibilité de réintégrer le nœud en panne
-sans le reconstruire à partir de zéro en tant qu'esclave.
-Si c'est possible, il est préférable d'utiliser la commande
- <xref linkend="stmtmoveset"/> car elle n'abandonne
- <emphasis>pas</emphasis> le nœud en panne.
- </para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtddlscript"><refmeta><refentrytitle>EXECUTE SCRIPT</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>EXECUTE SCRIPT</refname>
-
- <refpurpose>Exécute un script SQL/DDL</refpurpose></refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>EXECUTE SCRIPT (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>Cette commande exécute un script contenant des ordres SQL sur
- tous les nœuds qui sont abonnés à un ensemble de réplication à un
- point précis dans le flux des transactions.</para>
-
- <para>L'origine de l'événement doit être l'origine de l'ensemble
-de réplication. Le fichier de script ne doit pas contenir d'ordres
-<command>START</command> ou <command>COMMIT TRANSACTION</command>.
- (Ceci change un peu avec &postgres; 8.0 puisque les transactions imbriquées,
-appelée également <quote>points de sauvegarde</quote> (<quote>
- savepoints</quote>), sont supportés.
-De plus, les ordres DML non déterministes (par exemple mettre à jour un
-champ avec la valeur <function>CURRENT_TIMESTAMP</function>) doivent
-être évitées car les changements effectués par ce script ne sont pas
-explicitement répliqués.</para>
-
- <variablelist>
- <varlistentry><term><literal>SET ID = ival</literal></term>
-
- <listitem><para>Le numéro unique de l'ensemble affecté par le script</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>FILENAME = '/chemin/vers/le/fichier'</literal></term>
-
- <listitem><para>Le nom du fichier contenant le script SQL à exécuter.
-Il peut s'agir d'un chemin relatif à l'emplacement de l'instance <application>slonik</application>
-que vous avez lancé ou, de préférence, un chemin absolu sur le système où
- <application>slonik</application> est lancé.</para>
-
- <para>Le <emphasis>contenu</emphasis> de ce fichier est propagé dans un
-événement, donc il n'est pas nécessaire que le fichier soit accessible depuis
-les autres nœuds.
- </para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>EVENT NODE = ival</literal></term>
- <listitem><para>(Optionnel) L'identifiant de l'origine courante de l'ensemble. La valeur par défaut est 1.</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>EXECUTE ONLY ON = ival</literal></term>
- <listitem><para>(Optionnel) L'identifiant du seul nœud qui
-doit exécuter le script. Cette option implique que le script sera propagé
-sur tous les nœuds mais exécuté sur un seul.
-Par défaut, on exécute le script sur tous les nœuds abonnés à l'ensemble de réplication.
- </para></listitem>
-
- </varlistentry>
- </variablelist>
-
- <para>Voir également les avertissements dans la section &rddlchanges;.</para>
-
- <para>Notons qu'il s'agit d'une opération &rlocking;, ce qui signifie qu'elle peut être
-bloquée par l'activité d'une autre base.</para>
-
- <para>Au démarrage de cet événement, toutes les tables répliquées sont
-déverrouillées par la fonction <function>alterTableRestore(tab_id)</function>.
-Une fois le script SQL exécuté, elles sont remises en <quote>mode réplication
-</quote> avec <function>alterTableForReplication(tab_id)</function>.
-Cela implique que toutes les tables sont verrouillées par ce processus
-&slon; pendant la durée du script SQL.</para>
-
- <para>Si les colonnes d'une table sont modifiées, il est très
-important que les triggers soient régénérés, sinon ils peuvent
-être inadaptés à la nouvelle forme du schéma.
- </para>
-
- <para>Notez que si vous devez faire référence au nom du cluster,
-vous pouvez utiliser l'alias <command>@CLUSTERNAME@</command> ;
-si vous devez faire référence au schéma &slony1;,
-vous pouvez utiliser l'alias <command>@NAMESPACE@</command> ;
-les deux seront remplacés par la valeur appropriée. </para>
-
- <para>Cette commande utilise &funddlscript;.</para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-EXECUTE SCRIPT (
- SET ID = 1,
- FILENAME = '/tmp/changes_2008-04-01.sql',
- EVENT NODE = 1
-);
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Sur les versions antérieures à la branche 2.0, un verrou exclusif est posé
-sur chaque table répliquée sur le nœud origine, afin de retirer les triggers
-de réplication. Une fois le script DDL achevé, ces verrous sont enlevés.
- </para>
-
- <para>Une fois le script DDL exécuté sur le nœud origine, il est lancé sur les nœuds
-abonnés. Des verrous similaires sont posés sur tous les nœuds pour altérer
-les triggers des tables répliquées.
- </para>
-
- <para>À partir de la branche 2.0, &slony1; utilise un GUC qui contrôle
-le comportement des triggers, ce qui permet de désactiver les triggers créés par
-&slony1; pendant l'opération <emphasis>sans</emphasis> poser de verrous exclusifs sur
-toutes les tables. Désormais, les seules tables qui sont verrouillées sont les tables
-qui sont effectivement modifiées par le script DDL.
- </para>
-
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
-
- <para>Avant la version 1.2, l'ensemble du script DDL était soumis
-dans une requête <function>PQexec()</function>, ce qui impliquait que
-le script <emphasis>tout entier</emphasis> était traité en se basant sur
-l'état de la base avant l'invocation du script. Cela signifie que
-des ordres placés à la fin d'un script ne pouvaient pas dépendre d'un ordre
-situé au début de ce même script. Ainsi, il n'était pas possible
-d'ajouter une colonne dans une table, puis une contrainte sur cette
-colonne au sein du même script.
- </para>
-
- <para>Dans &slony1; version 1.2, le script DDL est découpé ordre par ordre,
-et chaque ordre est soumis séparément. Cela implique que les ordres de la fin
-du script peuvent se référer aux objets ou aux attributs créés et modifiés au début
-du script.
-De plus, dans la version 1.2, le résultat de sortie de <command>slonik</command>
-contient la liste des ordre au fur et à mesure de leur traitement sur le nœud
-d'origine de l'ensemble de réplication. De même, les ordres traités sont listés
-dans les logs de slon sur les autres nœuds.
- </para>
-
- <para>Dans &slony1; version 1.0, cette commande verrouille uniquement les tables
-de l'ensemble spécifié. À partir de la version 1.1, <emphasis>toutes
-les tables répliquées</emphasis> sont verrouillées (<emphasis>c'est-à-dire</emphasis>
-que les triggers sont retirés au départ et restaurés à la fin).
-Ceci couvre les risques lorsqu'on lance une requête de changements DDL
-sur des tables appartenant à plusieurs ensemble de réplication.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtupdatefunctions"><refmeta><refentrytitle>UPDATE FUNCTIONS</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>UPDATE FUNCTIONS</refname>
-
- <refpurpose>Recharge les procédures stockées</refpurpose></refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>UPDATE FUNCTIONS (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Cette commande recharge les procédures stockées pour un nœud.</para>
-
- <para>Elle restaure toutes les procédures stockées et les définitions de fonctions dans
-le schéma &slony1; pour un nœud donné. Cette commande fait habituellement partie des
-procédure de mise à jour logicielles.
- </para>
-
- <variablelist>
- <varlistentry><term><literal>ID = ival</literal></term>
-
- <listitem><para>Le nœud à rafraîchir.</para></listitem>
-
- </varlistentry>
- </variablelist>
-
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-UPDATE FUNCTIONS (
- ID = 3 # Update functions on node 3
-);
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
- <refsect1> <title>Bizarreries</title>
-
- <para>Toute incohérence entre <xref linkend="slonik"/> et la bibliothèque C
- <quote>résidant</quote> dans l'installation de &postgres; empêchera le
-bon fonctionnement de l'ensemble et provoquera probablement une panne.
-Vous pouvez <emphasis>penser</emphasis> que vous mettez à jour avec la version
-1.1.5, mais si vous êtes en train d'utiliser la version 1.1.2, ou si vous
-n'avez pas redémarré la base avec une version qui a les bibliothèques 1.1.5,
-et que vous référencez des procédures stockées en C de la version 1.1.1,
-la tentative de mise à jour va échouer car les fonctionss C
-sont régulièrement modifiées entre les versions majeures.
- </para>
-
- <para>Avant &slony1; 1.2, le message d'erreur affiché n'était pas
-très informatif. Ce qu'on trouvait dans les traces de &postgres; était une
-erreur signalant l'impossibilité de charger des procédures stockées implémentées
-en C. À partir de la version 1.2, une des premières actions effectuées est
-le chargement d'une procédures stockées pour vérifier les numéros de versions ;
-Un message bien plus clair est affiché si vous utilisez des versions non
-cohérentes.
- </para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtwaitevent"><refmeta><refentrytitle>WAIT FOR EVENT</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>WAIT FOR EVENT</refname>
-
- <refpurpose>Demander à un script Slonik d'attendre que l'événement précédent s'achève</refpurpose></refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>WAIT FOR EVENT (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Cette commande attend une confirmation d'événement.</para>
-
- <para><application>Slonik</application> se souvient du dernier événement
-généré sur chaque nœud pendant l'exécution d'un script (les événements produits
-lors des appels précédents ne sont pas vérifiés). Dans certaines situations,
-il est nécessaire que des événements générés sur un nœud (tel que
- <command>CREATE SET</command>) soient traités sur un autre nœud avant de
-lancer d'autres commandes (par exemple <xref linkend="stmtsubscribeset"/>).
-<command>WAIT FOR EVENT</command> peut être utilisé pour demander à un
-script <application>slonik</application> d'attendre jusqu'à ce que le nœud abonné
-soit prêt pour l'action suivante.
- </para>
-
- <para><command>WAIT FOR EVENT</command> doit être appelée en dehors d'un
-bloc <command>try</command> car les nouveaux messages de confirmation ne sont
-pas visibles à l'intérieur d'une transaction.
-
- <variablelist>
- <varlistentry><term><literal>ORIGIN = ival | ALL</literal></term>
- <listitem><para>L'origine de l'événement qu'il faut attendre.</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>CONFIRMED = ival | ALL</literal></term>
-
- <listitem><para>L'identifiant du nœud récepteur qui doit confirmer le(s)
-événement(s).
-</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>WAIT ON = ival</literal></term>
- <listitem><para>L'identifiant du nœud où la table &slconfirm; est vérifiée.
-La valeur par défaut est 1.</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>TIMEOUT = ival</literal></term>
-
- <listitem><para>Le nombre de secondes d'attente. La valeur par défaut est 600
- (10 minutes). <command>TIMEOUT = 0</command> implique que le script attend
-indéfiniment.</para></listitem>
-
- </varlistentry>
- </variablelist></para>
-
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-WAIT FOR EVENT (
- ORIGIN = ALL,
- CONFIRMED = ALL,
- WAIT ON = 1
-);
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0.</para>
- </refsect1>
-
- <refsect1> <title>Bizarreries</title>
-<para>Tous les événements ne retournent pas forcément des résultats intéressants.
-Par exemple, beaucoup de gens ont rencontré énormément de problèmes avec
-<xref linkend="stmtsubscribeset"/> lorsqu'ils abonnaient un nouvel ensemble.
-Soyez conscient que la requête <xref linkend="stmtsubscribeset"/> va retourner
-la confirmation d'événement presque immédiatement, même s'il reste plusieurs heures
-de travail avant que l'abonnement ne soit achevé. Le problème avec
- avec <xref linkend="stmtsubscribeset"/> est qu'il est traité par
-<emphasis>deux</emphasis> événements, un sur le nœud origine et un autre
- qui met en place l'abonnement sur l'abonné.
- </para>
-
- <para>Afin de surveiller plus étroitement à l'intérieur du script <xref
- linkend="slonik"/> que l'instruction <xref linkend="stmtsubscribeset"/>
-est complète, vous pouvez soumettre un événement <xref linkend="stmtsync"/>
-après l'abonnement et lancer une requête WAIT sur ce
- <command>SYNC</command>, de la manière suivante : </para>
- <programlisting>
- # Supposons que l'ensemble 1 a deux abonnés direct 2 et 3
- SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 2);
- SYNC (ID=1);
- WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 2, WAIT FOR=1);
- SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 3);
- SYNC (ID=1);
- WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 3, WAIT FOR=1);
- MERGE SET ( ID = 1, ADD ID = 999, ORIGIN = 1 );
- </programlisting>
- </refsect1>
-
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id="stmtrepairconfig"><refmeta><refentrytitle>REPAIR CONFIG</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>REPAIR CONFIG</refname>
-
- <refpurpose>Remet à zéro les tables de correspondance entre les noms et les OID pour un
-ensemble de réplication, utile lorsqu'on restaure un nœud après un
-<application>pg_dump</application>.</refpurpose></refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>REPAIR CONFIG (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Remet à zéro la correspondance entre noms et OID.</para>
-
- <variablelist>
- <varlistentry><term><literal>SET ID = ival</literal></term>
- <listitem><para>Le numéro de l'ensemble à nettoyer.</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>EVENT NODE = ival</literal></term>
-
- <listitem><para>L'identifiant du nœud ou la commande doit être soumise.</para></listitem>
-
- </varlistentry>
- <varlistentry><term><literal>EXECUTE ONLY ON = ival</literal></term>
-
- <listitem><para>L'identifiant du seul nœud où la correspondance est mise à jour.
- Si cette valeur n'est pas précisée, par défaut on exécute la commande sur tous les
- nœuds abonnés à l'ensemble.</para></listitem>
-
- </varlistentry>
- </variablelist>
-
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-REPAIR CONFIG (
- SET ID = 1,
- EVENT NODE = 2
-);
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.1.</para>
- </refsect1>
- </refentry>
-<!-- **************************************** -->
-
- <refentry id="stmtsync"><refmeta><refentrytitle>SYNC</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>SYNC</refname>
-
- <refpurpose>Cette commande produit un événement SYNC ordinaire.</refpurpose></refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>SYNC (options);</command>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
-
- <para>Cette commande génère un événement SYNC sur un nœud donné.</para>
-
- <variablelist>
- <varlistentry><term><literal>ID = ival</literal></term>
- <listitem><para>Le nœud sur lequel on génère l'événement SYNC.</para></listitem>
-
- </varlistentry>
- </variablelist>
-
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- SUBSCRIBE SET (ID = 10, PROVIDER = 1, RECEIVER = 2);
- WAIT FOR EVENT (ORIGIN = 2, CONFIRMED = 1);
- SYNC (ID = 1);
- WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 2);
- </programlisting>
- </refsect1>
- <refsect1> <title>Utilisation de verrous</title>
-
- <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.1.6 / 1.2.1.</para>
- </refsect1>
- </refentry>
-
-<!-- **************************************** -->
-
- <refentry id ="stmtsleep"><refmeta><refentrytitle>SLEEP</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>SLEEP</refname>
-
- <refpurpose>S'endormir avec la fonction système <function>sleep()</function></refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>sleep </command>
- <arg><replaceable class="parameter"> secondes</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>
- Cette commande endort les opérations pendant un certain nombre de secondes.
- </para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- sleep (seconds = 5);
- </programlisting>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.1.6 / 1.2.1.</para>
- </refsect1>
- </refentry>
-
- <refentry id ="stmtcloneprepare"><refmeta><refentrytitle>CLONE PREPARE</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>CLONE PREPARE</refname>
-
- <refpurpose>Prépare le clonage d'un nœud.</refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>clone prepare</command>
- <arg><replaceable class="parameter">id</replaceable></arg>
- <arg><replaceable class="parameter">provider</replaceable></arg>
- <arg><replaceable class="parameter">comment</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>
- Cette commande prépare le clonage d'un nœud donné.
- </para>
-
- <para>
- Ceci duplique la configuration d'un nœud <quote>fournisseur</quote>
- sous un nouvel identifiant en préparation de la copie de ce nœud
- via un outil standard.
- </para>
-
- <para>Notez que pour être certain que ce nouveau nœud est cohérent avec
-tous les nœuds, il est important de lancer un événement SYNC sur tous les
-nœuds à l'exception du fournisseur et d'attendre que tous ces événements
-SYNC soient confirmés avant de copier la base fournisseur.
-Sinon il est possible que le clone ait raté des événements.
- </para>
-
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- clone prepare (id = 33, provider = 22, comment='Clone 33');
- sync (id=11);
- sync (id=22);
- </programlisting>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.2.0.</para>
- </refsect1>
- </refentry>
- <refentry id ="stmtclonefinish"><refmeta><refentrytitle>CLONE FINISH</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
- <refnamediv><refname>CLONE FINISH</refname>
- <refpurpose>Termine le clonage d'un nœud.</refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>clone prepare</command>
- <arg><replaceable class="parameter">id</replaceable></arg>
- <arg><replaceable class="parameter">provider</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>
- Cette commande achève le clonage sur un nœud donné.
- </para>
- <para>Ceci complète le travail effectué par <xref linkend="stmtcloneprepare"/> en établissant les données de confirmation
- pour le nouveau <quote>clone</quote> à partir du statut trouvé pour le nœud <quote>fournisseur</quote>.
- </para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- clone finish (id = 33, provider = 22);
- </programlisting>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.2.0.</para>
- </refsect1>
- </refentry>
-
-
- </reference>
Copied: traduc/tags/slony_1_2_12/slonik_ref.xml (from rev 1244, traduc/trunk/slony/slonik_ref.xml)
===================================================================
--- traduc/tags/slony_1_2_12/slonik_ref.xml (rev 0)
+++ traduc/tags/slony_1_2_12/slonik_ref.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,2889 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<article id="slonikref">
+<title>Tour d'horizon des commandes Slonik</title>
+ <sect1><title>Introduction</title>
+ <para><application>Slonik</application> est un utilitaire en ligne de commande
+ conçu spécifiquement pour mettre en place et modifier la configuration
+ du système de réplication &slony1;.</para>
+ <sect2 id="outline">
+ <title>Considérations générales</title>
+ <para>
+ L'utilitaire en ligne de commande <application>slonik</application>
+ est supposé être intégré dans des scripts shell et lit
+ les commandes à partir d'un fichier ou de stdin (voir plus
+ bas pour des exemples). Presque tout le travail de configuration
+ <emphasis>réel</emphasis> est effectué en appelant des procédures
+ stockées après avoir chargé la base de support &slony1; dans
+ la base de données. Vous pouvez trouver de la documentation sur
+ ces procédures dans le chapitre <ulink url="schemadoc">Documentation
+ du schéma de &slony1;</ulink>, ainsi que dans les commentaires
+ qui sont associés aux procédures dans la base de données.
+ </para>
+ <para>
+ <application>Slonik</application> a été créé car :
+ <itemizedlist>
+
+ <listitem><para>Les procédures stockées ont des besoins d'informations
+ spécifiques telles que l'identifiant du nœud de réplication
+ sur lequel elles sont appelées ;</para></listitem>
+
+ <listitem><para>L'absence de paramètres nommés dans les
+ procédures stockées rend difficile de faire cela depuis
+ l'invite de commande <application>psql</application> ;
+ </para></listitem>
+
+ <listitem><para><application>psql</application> n'a pas la possibilité
+ de maintenir plusieurs connexions avec des transactions ouvertes.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ <para>
+
+ </para>
+ <sect3><title>Commandes</title>
+ <para>Le format du langage de commande slonik est libre.
+ Les commandes commencent par des mots-clefs et sont terminées
+ par un point-virgule. La plupart des commandes ont une liste de
+ paramètres, certains ont une valeur par défaut et sont donc
+ facultatifs. Les paramètres de commandes sont entourés par des
+ parenthèses. Chaque option est constituée d'un ou plusieurs
+ mots-clefs, suivis d'un symbole égal, suivi d'une valeur. Les
+ options multiples à l'intérieur de parenthèses sont séparées par
+ des virgules. Tous les mot-clefs sont sensibles à la casse. Le
+ langage devrait rappeler le SQL.</para>
+ <para>Les valeurs d'option peuvent être :</para>
+ <itemizedlist>
+ <listitem><para>des entiers ;</para></listitem>
+ <listitem><para>des chaînes de caractères entourés de guillemets ;</para></listitem>
+ <listitem><para>des valeurs booléennes {TRUE|ON|YES} ou {FALSE|OFF|NO} ;</para></listitem>
+ <listitem><para>des mots-clefs dans des cas spécifiques.</para></listitem>
+ </itemizedlist>
+
+ </sect3>
+ <sect3><title>Commentaires</title>
+ <para>Les commentaires commencent par un dièse (#) et vont jusqu'à la fin de la ligne.</para>
+ </sect3>
+ <sect3><title>Groupes de commandes</title>
+ <para>Les commandes peuvent être combinées par groupes de commandes avec une
+ éventuellement une condition <command>on error</command> et
+ <command>on success</command>.
+ La syntaxe est la suivante :
+ <programlisting>
+ try {
+ commands;
+ }
+ [on error { commands; }
+ [on success { commands; }
+ </programlisting></para>
+
+ <para>Ces commandes sont regroupées ensemble au sein d'une transaction
+ pour chaque nœud participant.</para>
+ </sect3>
+ </sect2>
+ </sect1>
+</article>
+<!-- ************************************************************ -->
+<reference id="metacmds">
+ <title>Méta-commandes Slonik</title>
+ <partintro>
+ <para>Les commandes suivantes sont utilisées pour séparer
+ les définitions des composants des scripts Slonik ;
+ <xref linkend="stmtinclude"/> regroupe la configuration
+ dans des fichiers centraux qui peuvent être réutilisés, et
+ <xref linkend="stmtdefine"/> permet de remplacer les identifiants
+ numériques et ésotériques des objets par des identifiants mnémotechniques.</para>
+ </partintro>
+ <!-- **************************************** -->
+ <refentry id ="stmtinclude">
+ <refmeta><refentrytitle>INCLUDE</refentrytitle><manvolnum>7</manvolnum></refmeta>
+ <refnamediv>
+ <refname>INCLUDE</refname>
+ <refpurpose>insérer du code slonik à partir d'un autre fichier</refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>include </command>
+ <arg><replaceable class="parameter"><chemin></replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>Ceci injecte le script slonik spécifié à l'intérieur du script actuel.
+ Si le <option>chemin</option> est relatif, <xref linkend="slonik"/>
+ cherchera à partir du répertoire de travail.</para>
+ <para>Les inclusions imbriquées sont supportées. Le scanner et l'analyseur
+ retournent le bon nom de fichier et le numéro ligne correcte en cas
+ d'erreur.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ include </tmp/preamble.slonik>;
+ </programlisting>
+ </refsect1>
+ <refsect1><title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.1.</para>
+ </refsect1>
+ </refentry>
+ <!-- **************************************** -->
+ <refentry id ="stmtdefine"><refmeta><refentrytitle>DEFINE</refentrytitle><manvolnum>7</manvolnum></refmeta>
+ <refnamediv><refname>DEFINE</refname>
+ <refpurpose>Définir un nom symbolique</refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>define </command>
+ <arg><replaceable class="parameter">nom</replaceable></arg>
+ <arg><replaceable class="parameter">valeur</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>Ceci définit un nom symbolique. Les noms symboliques doivent
+ respecter les règles de slonik en matière de construction d'identifiants,
+ en commençant par une lettre, suivie de lettres, de nombres et de soulignés
+ (« _ »).</para>
+ <para>Les valeurs des noms symboliques peuvent contenir des espaces et peuvent contenir
+ des références à des noms symboliques, de manière récursive.</para>
+ <para>Les symboles sont référencés en utilisant une arobase <quote>@</quote> suivi
+ du nom symbolique. Notons que le référencement d'un symbole est annulé
+ à l'intérieur des chaînes de caractères.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ define cluster films;
+ define sakai 1;
+ define chen 2;
+ define fqn fully qualified name;
+
+ cluster name = @cluster;
+ node @sakai admin conninfo = 'service=sakai-replication';
+ node @chen admin conninfo = 'service=chen-replication';
+ define setFilms id = 1;
+ define sakaiFilms @setFilms, origin = @sakai;
+
+ create set ( @sakaiFilms, comment = 'films' );
+
+ set add table( set @sakaiFilms, id = 1, @fqn = 'public.clients',
+ comment = 'sakai customers' );
+ set add table( set @sakaiFilms, id = 2, @fqn = 'public.cassettes',
+ comment = 'sakai cassettes' );
+ echo '@sakaiFilms sera affiché comme une chaîne, et ne sera pas interprété';
+ </programlisting>
+ </refsect1>
+
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.1.</para>
+ </refsect1>
+ </refentry>
+</reference>
+
+<!-- **************************************** -->
+
+<reference id="hdrcmds">
+ <title>Commandes slonik préliminaires</title>
+ <partintro>
+ <para>Les commandes suivantes doivent apparaître en <quote>préambule</quote>
+ de chaque script de commande <application>slonik</application>.
+ Ils ne provoquent aucune action directement sur les nœuds du
+ système de réplication, mais affecte l'exécution du script tout entier.</para>
+ </partintro>
+ <refentry id ="clustername">
+ <refmeta><refentrytitle>CLUSTER NAME</refentrytitle><manvolnum>7</manvolnum></refmeta>
+ <refnamediv>
+ <refname>CLUSTER NAME</refname>
+ <refpurpose>préambule - identifier le cluster &slony1;</refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>CLUSTER NAME = </command>
+ <arg><replaceable class="parameter">nom</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>Ceci doit être la toute première ligne de chaque script
+ <application>slonik</application>. Elle définit le schéma
+ dans lequel toutes les fonctions spécifiques, les procédures,
+ les tables et les séquences de &slony1; sont déclarées.
+ Le nom du schéma est construit en préfixant la chaîne
+ de caractères fournie par un souligné. Ce schéma sera
+ identique sur toutes les bases de données qui participent
+ au même groupe de réplication.</para>
+
+ <para>Aucun objet utilisateur n'est supposé être placé dans ce schéma,
+ et ce schéma ne doit pas exister avant l'ajout de la base de données
+ dans le système de réplication. Ainsi, si vous ajoutez un nouveau nœud
+ en utilisant <command>pg_dump -s</command> sur une base qui est déjà
+ dans le cluster de réplication, vous devrez supprimer le schéma
+ avec la commande SQL <command> DROP SCHEMA _testcluster CASCADE;</command>.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ CLUSTER NAME = testcluster;
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+ <refentry id ="admconninfo">
+ <refmeta><refentrytitle>ADMIN CONNINFO</refentrytitle><manvolnum>7</manvolnum></refmeta>
+ <refnamediv>
+ <refname>ADMIN CONNINFO</refname>
+ <refpurpose>preambule - identifier la base &postgres;</refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>NODE ival ADMIN CONNINFO = 'DSN';</command>
+ <arg><replaceable class="parameter">ival</replaceable></arg>
+ <arg><replaceable class="parameter">'conninfo'</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>Décrit comment l'utilitaire <application>slonik</application> peut
+ atteindre les bases des nœuds du cluster à partir de l'endroit
+ où il se trouve (en général le poste de travail de l'administrateur).
+ La chaîne connifo est l'argument passé à la fonction
+ libpq <function>PQconnectdb()</function>. L'utilisateur qui se connecte
+ doit être un super-utilisateur spécifique à la réplication car certaines
+ actions réalisées par la suite comprennent des opérations strictement réservées
+ aux super-utilisateurs du serveur &postgres;.</para>
+
+ <para>L'utilitaire <application>slonik</application> n'essaie de se connecter
+ à une base de donnée que si une commande nécessite une connexion.</para>
+
+ <note><para>Comme indiqué dans les document originaux, &slony1; est conçu comme
+ un système de réplication d'entreprises pour centres de données. Lors du développement
+ du logiciel, on présuppose que les serveurs de bases de données et les postes
+ de travail impliqués dans la réplication et/ou dans les activités de mise en place et
+ de configuration peuvent utiliser des méthodes simples d'authentification telle que
+ <quote>trust</quote>. Cependant, libpq peut lire les mots de passe dans le fichier
+ <filename>.pgpass</filename>.</para></note>
+ <note><para>Si vous devez changer les informations DSN pour un nœud, par exemple si
+ l'adresse IP d'un hôte est modifiée, vous devez soumettre cette nouvelle
+ information avec la commande <xref linkend="stmtstorepath"/>,
+ et la configuration sera propagée. Certains processus
+ <application>slon</application> existant devront être relancés afin qu'ils
+ soient avertis de ce changement de configuration.</para></note>
+
+ <para>Pour plus de détails sur la distinction entre ceci et <xref
+ linkend="stmtstorepath"/>, consultez le chapitre &rplainpaths;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+</reference>
+
+<!-- ************************************************************ -->
+<reference id="cmds">
+ <title>Commande de configuration et d'action</title>
+ <refentry id ="stmtecho">
+ <refmeta>
+ <refentrytitle>ECHO</refentrytitle><manvolnum>7</manvolnum></refmeta>
+ <refnamediv>
+ <refname>ECHO</refname>
+ <refpurpose>Outil générique de sortie</refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>echo</command>
+ <arg><replaceable class="parameter">'message'</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>Affiche un message littéral sur la sortie standard.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ ECHO 'Nœud 1 initialisé correctement';
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+ <!-- **************************************** -->
+
+ <refentry id ="stmtexit"><refmeta><refentrytitle>EXIT</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>EXIT</refname>
+
+ <refpurpose>Termine un script Slonik avec un signal</refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>exit</command>
+ <arg><replaceable class="parameter"> [-]ival</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>
+ Termine immédiatement un script d'exécution, annulant toute
+ les transactions ouvertes (ROLLBACK) sur toutes les bases de données
+ connectées. L'utilitaire <application>slonik</application> retournera
+ la valeur indiquée comme code de terminaison du programme.
+ </para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ EXIT 0;
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+ <!-- **************************************** -->
+ <refentry id="stmtinitcluster">
+ <refmeta>
+ <refentrytitle>INIT CLUSTER</refentrytitle>
+ <manvolnum>7</manvolnum>
+ </refmeta>
+ <refnamediv>
+ <refname>INIT CLUSTER</refname>
+ <refpurpose>Initialise le cluster &slony1;</refpurpose></refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>INIT CLUSTER</command>
+ <arg>ID = <replaceable class="parameter">entier</replaceable></arg>
+ <arg>COMMENT = <replaceable class="parameter">'chaîne'</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para> Initialise le premier nœud d'un nouveau cluster de réplication &slony1;.
+ Le processus d'initialisation consiste à créer le schéma du cluster, à
+ charger toutes les tables, les fonctions, les procédures et à initialiser le nœud
+ avec &funinitializelocalnode; et &funenablenode;.
+
+ <variablelist>
+ <varlistentry><term><literal>ID</literal></term>
+ <listitem><para>L'identifiant numérique et unique du nœud.</para></listitem>
+ </varlistentry>
+
+ <varlistentry><term><literal>COMMENT = 'commentaire'</literal></term>
+ <listitem><para>Un texte descriptif ajouté à la ligne du nœud dans
+ la table &slnode;.
+ </para></listitem>
+ </varlistentry>
+ </variablelist>
+
+ </para>
+
+ <para>Pour que ce processus fonctionne, les scripts SQL du système
+ &slony1; doivent être installés sur le poste de travail de l'administrateur
+ (l'ordinateur utilisé pour exécuter l'utilitaire <application>slonik</application>),
+ tandis que sur le serveur qui héberge le nœud de base de donnée contenant les
+ objets partagés, &slony1; doit être installé dans le répertoire qui contient
+ les bibliothèques de &postgres;. De plus le langage procédural
+ PL/pgSQL doit être installé au préalable sur la base de données cible.
+ </para>
+ </refsect1>
+ <refsect1>
+ <title>Exemple</title>
+ <programlisting>
+INIT CLUSTER (
+ ID = 1,
+ COMMENT = 'Nœud 1'
+);
+ </programlisting>
+
+ <note> <para> Cette commande fonctionne de manière similaire à
+ <xref linkend="stmtstorenode"/>, la différence étant que <command>INIT
+ CLUSTER</command> n'a pas besoin de récupérer la configuration des autres nœuds.
+ </para> </note>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Cette commande crée un nouveau schéma et configure les
+ tables à l'intérieur ; aucun objet public ne doit être verrouillé
+ pendant l'exécution de cette commande.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id ="stmtstorenode"><refmeta><refentrytitle>STORE NODE</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>STORE NODE</refname>
+ <refpurpose>Initialise un nœud &slony1;</refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>STORE NODE (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Initialise un nouveau nœud et l'ajoute dans la configuration du
+ cluster existant.</para>
+
+ <para>Le processus d'initialisation consiste à la création du schéma
+ sur le nouveau nœud (la base elle-même doit déjà exister), au
+ chargement des tables, des fonctions, des procédures et à l'initialisation
+ du nœud. La configuration existante du reste du nœud est copiée
+ à partir d'un <quote>nœud d'événement</quote>.
+
+ <variablelist>
+ <varlistentry><term><literal>ID = ival</literal></term>
+ <listitem><para>L'identifiant numérique et unique du nouveau nœud.</para></listitem>
+ </varlistentry>
+
+ <varlistentry><term><literal> COMMENT = 'description' </literal></term>
+ <listitem><para>Un texte descriptif ajouté à la ligne du nœud dans
+ la table &slnode;</para></listitem>
+ </varlistentry>
+
+ <varlistentry><term><literal>SPOOLNODE = booléen</literal></term>
+
+ <listitem><para>Spécifie qu'un nœud est un nœud virtuel de récupération
+ pour l'archivage de journaux de réplication. Si ce paramètre est à true,
+ <application>slonik</application> n'essaiera pas d'initialiser la base de
+ donnée avec le schéma de réplication.</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>EVENT NODE = ival</literal></term>
+
+ <listitem><para>L'identifiant du nœud utilisé pour créer l'événement de configuration,
+ qui prévient tous les nœuds existants de l'arrivée du nouveau nœud.
+ La valeur par défaut est 1.</para></listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <para>Ceci utilise &funinitializelocalnode; et &funenablenode;.</para>
+
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ STORE NODE ( ID = 2, COMMENT = 'Nœud 2');
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Cette commande crée un nouveau schéma et configure les tables
+ à l'intérieur ; aucun objet public ne doit être verrouillé
+ pendant l'exécution de cette commande.</para>
+ </refsect1>
+
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0. Le paramètre <envar>SPOOLNODE</envar>
+ fut introduit dans la version 1.1 mais n'était pas implémentée dans cette version.
+ La fonctionnalité <envar>SPOOLNODE</envar> est arrivée dans la
+ version 1.2.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+ <refentry id="stmtdropnode"><refmeta><refentrytitle>DROP NODE</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>DROP NODE</refname>
+
+ <refpurpose>Supprime un nœud de la réplication</refpurpose></refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>DROP NODE (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>
+ Supprime un nœud. Cette commande retire complètement le nœud spécifié
+ de la configuration du système de réplication.
+ Si le démon de réplication est toujours en fonctionnement sur ce nœud
+ (et qu'ils traitent les événements), il tentera de désinstaller le système
+ de réplication et s'arrêtera de lui-même.
+
+ <variablelist>
+ <varlistentry><term><literal> ID = ival </literal></term>
+ <listitem><para>L'identifiant du nœud à supprimer.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal> EVENT NODE = ival </literal></term>
+ <listitem><para>L'identifiant du nœud qui génère l'événement. La valeur par défaut est 1.
+ </para></listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <para>Cette commande utilise &fundropnode;.</para>
+
+ <para>Quand vous invoquez <command>DROP NODE</command>, une des étapes
+ consiste à lancer <command>UNINSTALL NODE</command>.</para>
+
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ DROP NODE ( ID = 2 );
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Lorsqu'on supprime des triggers d'une table de l'application,
+ cela nécessite un accès exclusif à chaque table répliquée sur le nœud
+ que l'on supprime.</para>
+ </refsect1>
+ <refsect1><title>Comportement dangereux ou non-intuitif</title>
+ <para>Si vous utilisez des connexions qui cachent les plans d'exécution
+ (ce qui est particulièrement commun pour les frameworks applicatifs Java utilisant
+ des pools de connexions), les connexions peuvent cacher des plans
+ de requêtes qui se basent sur une vision pré-<command>DROP NODE</command>,
+ ce qui implique que vous obtiendrez des &rmissingoids;.</para>
+
+ <para>Ainsi après avoir supprimé un nœud, il est préférable de réinitialiser
+ les connexions de votre applications.</para>
+
+ <para>Vous ne pouvez pas soumettre cela à un <command>EVENT
+ NODE</command> ayant le même numéro que le nœud que vous supprimez ;
+ la requête doit aller vers un nœud qui restera dans le cluster.
+ </para>
+ </refsect1>
+
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+ <refentry id="stmtuninstallnode"><refmeta><refentrytitle>UNINSTALL NODE</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>UNINSTALL NODE</refname>
+
+ <refpurpose>Désinstaller un nœud &slony1;</refpurpose></refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>UNINSTALL NODE (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Restaure toutes les tables dans leur état non verrouillé, avec
+ les triggers d'origines, les contraintes et les règles. Les éventuelles colonnes
+ spécifiques de &slony1; contenant des clefs SERIAL sont supprimées.
+ Enfin, le schéma &slony1; est effacé. Le nœud redevient une base de données
+ indépendante. Les données ne sont pas modifiées.
+ <variablelist>
+ <varlistentry><term><literal>ID = ival</literal></term>
+ <listitem><para>Identifiant du nœud à désinstaller.</para></listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <para>Cette commande utilise &fununinstallnode;.</para>
+
+ <para>La différence entre <command>UNINSTALL NODE</command>
+ et <command>DROP NODE</command> est que <command>UNINSTALL
+ NODE</command> se contente de supprimer la configuration &slony1; ;
+ il ne retire la configuration du nœud sur l'ensemble de réplication.
+ </para>
+
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ UNINSTALL NODE ( ID = 2 );
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Lorsqu'on supprime les triggers des tables de l'application,
+ cela nécessite un accès exclusif à chaque table répliquée sur le nœud
+ que l'on désinstalle.</para>
+ </refsect1>
+ <refsect1><title>Comportement dangereux ou non-intuitif</title>
+ <para>Si vous utilisez des connexions qui cachent les plans d'exécution
+ (ce qui est particulièrement commun pour les frameworks applicatifs Java utilisant
+ des pools de connexion), les connexions peuvent cacher des plans
+ de requêtes qui se basent sur une vision pré-<command>UNINSTALL NODE</command>,
+ ce qui implique que vous obtiendrez des &rmissingoids;.</para>
+
+ <para>Ainsi après avoir désinstallé un nœud, il est préférable de réinitialiser
+ les connexions de votre applications.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtrestartnode"><refmeta><refentrytitle>RESTART NODE</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>RESTART NODE</refname>
+
+ <refpurpose>Redémarre un nœud &slony1;</refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>RESTART NODE (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para> Provoque l'arrêt et le redémarrage d'un démon
+ de réplication sur le nœud spécifié.
+ Théoriquement, cette commande est obsolète. En pratique,
+ les délais TCP peuvent retarder les changements critiques
+ de configuration jusqu'à ce qu'il soit effectué alors que le
+ nœud expéditeur est en échec et doit être ignoré par les
+ nœuds abonnés.
+ <variablelist>
+ <varlistentry><term><literal>ID = ival</literal></term>
+ <listitem><para>Identifiant du nœud à redémarrer.</para></listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ RESTART NODE ( ID = 2 );
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0 ;
+ Elle ne devrait plus être nécessaire à partir de la version 1.0.5.</para>
+ </refsect1>
+ </refentry>
+
+
+ <!-- **************************************** -->
+
+ <refentry id="stmtstorepath"><refmeta><refentrytitle>STORE
+ PATH</refentrytitle><manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>STORE PATH</refname>
+
+ <refpurpose>Configure la connexion d'un nœud &slony1;</refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>STORE PATH (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Configure la connexion d'un démon de réplication d'un nœud
+ à la base de données d'un autre nœud. Si le système
+ de réplication est supposé utiliser un segment spécial de réseau,
+ c'est ici qu'on définit les adresses IP ou les noms d'hôtes.
+ Une configuration existante peut se trouver écrasée.
+ </para>
+
+ <para>Le paramètre conninfo doit contenir toutes les informations
+ pour se connecter à la base en tant super-utilisateur de la réplication.
+ Les termes <quote>serveur</quote> et <quote>client</quote> n'ont
+ rien à voir avec le rôle particulier d'un nœud dans la configuration
+ d'un cluster. On peut simplement voir cela comme un
+ <quote>serveur</quote> ayant un message or une donnée qu'un
+ <quote>client est supposé obtenir</quote>.
+ Pour une installation simple avec deux nœuds, les chemins dans les deux
+ directions doivent être configurés.
+ </para>
+ <para>Il ne pose aucun problème de configurer un chemin entre chaque
+ nœud (produit en croix complète). Les connexions ne sont établis que
+ si cela est nécessaire pour transférer un événement ou une confirmation
+ à cause des entrées <emphasis>listen</emphasis> ou une donnée à cause de
+ <emphasis>souscriptions</emphasis>.
+
+ <variablelist>
+ <varlistentry><term><literal>SERVER = ival</literal></term>
+ <listitem><para>Identifiant du nœud de la base à laquelle on doit se connecter.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>CLIENT = ival</literal></term>
+ <listitem><para>Identifiant du nœud du démon de réplication qui se connecte.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>CONNINFO = string</literal></term>
+ <listitem><para>Argument <function>PQconnectdb()</function> pour établir la connexion.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>CONNRETRY = ival</literal></term>
+ <listitem><para>Nombre de secondes d'attente avant qu'un autre tentative
+ de connexion soit faite dans le cas où le serveur est indisponible.
+ La valeur par défaut est 10.
+ </para></listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ <para>Cette commande utilise &funstorepath;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+STORE PATH ( SERVER = 1, CLIENT = 2,
+ CONNINFO = 'dbname=testdb host=serveur1 user=slony'
+ );
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+
+<!-- **************************************** -->
+
+ <refentry id="stmtdroppath"><refmeta><refentrytitle>DROP PATH</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>DROP PATH</refname>
+
+ <refpurpose>Supprime un chemin de connexion &slony1;</refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>DROP PATH (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Supprime les informations de connexion entre un <quote>serveur</quote> et un
+ <quote>client</quote>.</para>
+
+ <variablelist>
+ <varlistentry><term><literal>SERVER = ival</literal></term>
+ <listitem><para>Identifiant du nœud de la base à laquelle on doit se connecter.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>CLIENT = ival</literal></term>
+ <listitem><para>Identifiant du nœud du démon qui se connecte.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>EVENT NODE = ival</literal></term>
+
+ <listitem><para> L'identifiant du nœud utilisé pour créer l'événement de configuration
+ qui annonce à tous les nœuds existants que le chemin a été supprimé.
+ La valeur par défaut est l'identifiant du nœud <quote>client</quote>.
+ </para></listitem>
+ </varlistentry>
+ </variablelist>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ DROP PATH ( SERVER = 1, CLIENT = 2 );
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+
+<!-- **************************************** -->
+
+ <refentry id="stmtstorelisten"><refmeta><refentrytitle>STORE LISTEN</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>STORE LISTEN</refname>
+
+ <refpurpose>Configure un nœud &slony1; en lui indiquant où il
+ doit écouter les événements</refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>STORE LISTEN (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Pour chaque entrée <quote>listen</quote>, le nœud récepteur demande
+ à un nœud fournisseur de lui envoyer les événements d'un autre nœud
+ ainsi que les confirmations en provenance de tous les autres nœuds existants.
+ Un <quote>chemin</quote> doit exister pour
+ que le récepteur (le client) puisse se connecter au fournisseur (le serveur).</para>
+
+ <para>Chaque nœud du système doit écouter les événements
+ de tous les autres nœuds. En règle générale, un abonné
+ (voir <xref linkend="stmtsubscribeset"/>) doit écouter les événements
+ d'un ensemble origine sur un fournisseur unique, qui lui envoie
+ les données. En retour, l'origine de l'ensemble de réplication
+ doit écouter les événements dans la direction opposée.
+ Un nœud peut écouter simultanément les événements d'un même ensemble d'origine
+ en provenance de différents fournisseurs. Cependant, pour traiter les
+ événements <command>SYNC</command> de cet ensemble d'origine, tous les
+ fournisseurs de données doivent avoir un niveau de synchronisation égal
+ ou supérieur, afin d'éviter des comportements de réplication trop
+ rapide.
+ </para>
+
+ <variablelist>
+ <varlistentry><term><literal>ORIGIN = ival</literal></term>
+ <listitem><para>L'identifiant du nœud d'origine que le récepteur écoute.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>PROVIDER = ival</literal></term>
+ <listitem><para>L'identifiant du nœud qui envoie au récepteur les événements
+ produits par le nœud origine. Si cette valeur n'est pas spécifiée,
+ il s'agit du nœud origine.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>RECEIVER = ival</literal></term>
+
+ <listitem><para>L'identifiant du nœud recevant les événements.</para></listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>Cette commande utilise &funstorelisten;.</para>
+ <para>Pour plus de détails, consultez &rlistenpaths;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ STORE LISTEN ( ORIGIN = 1, RECEIVER = 2, PROVIDER = 3 );
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title> <para>Cette commande fut introduite
+ dans &slony1; 1.0. À partir de la version 1.1, vous ne <emphasis>devriez</emphasis>
+ pas avoir besoin de cette commande car les voies d'écoute sont générées automatiquement.
+ </para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtdroplisten"><refmeta><refentrytitle>DROP LISTEN</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>DROP LISTEN</refname>
+
+ <refpurpose>Élimine la configuration qui décrit comment un nœud
+ &slony1; écoute les événements
+ </refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>DROP LISTEN (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Supprime une <quote>voie d'écoute</quote> de la configuration.</para>
+
+ <variablelist>
+ <varlistentry><term><literal>ORIGIN = ival</literal></term>
+ <listitem><para>Identifiant du nœud origine que le récepteur écoute.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>PROVIDER = ival</literal></term>
+ <listitem><para>Identifiant du nœud qui envoie au récepteur les événements
+ produits par l'origine. Si cette valeur n'est pas spécifiée, alors il
+ s'agit de l'origine.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>RECEIVER = ival</literal></term>
+
+ <listitem><para>L'identifiant du nœud qui reçoit les événements.</para></listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>Cette commande utilise &fundroplisten;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ DROP LISTEN ( ORIGIN = 1, RECEIVER = 2, PROVIDER = 3 );
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title> <para>Cette commande fut introduite
+ dans &slony1; 1.0. À partir de la version 1.1, vous ne <emphasis>devriez</emphasis>
+ pas avoir besoin de cette commande car les voies d'écoute sont générées automatiquement.
+ </para>
+ </refsect1>
+ </refentry>
+
+
+<!-- **************************************** -->
+
+<refentry id="stmttableaddkey"><refmeta><refentrytitle>TABLE ADD KEY</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>TABLE ADD KEY</refname>
+
+ <refpurpose> Ajoute une clef primaire pour
+ &slony1; dans une table qui n'en possède pas
+ </refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>TABLE ADD KEY (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>
+ Dans un système de réplication &slony1;, chaque table répliquée
+ doit avoir au moins une contrainte
+ <command>UNIQUE</command> dont les colonnes sont déclarées
+ <command>NOT NULL</command>. N'importe quel clef primaire
+ respecte ces pré-requis.
+ </para>
+
+ <para>
+ En dernier recours, cette commande peut être utilisée pour ajouter
+ un attribut à une table qui ne possède par de clef primaire.
+ Sachant que cette modification peut avoir des effets secondaires
+ indésirables, <emphasis>il est très fortement recommandé que les
+ utilisateurs ajoutent les attributs unique et not null par
+ leurs propres moyens</emphasis>.
+ </para>
+
+ <variablelist>
+ <varlistentry><term><literal>NODE ID = ival</literal></term>
+ <listitem><para>Identifiant du nœud de l'ensemble de réplication d'origine
+ où l'on ajoute la table dans l'ensemble (voir <xref linkend="stmtsetaddtable"/>).</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>FULLY QUALIFIED NAME = 'string'</literal></term>
+ <listitem><para>Le nom complet de la table composé du nom du schéma
+ et du nom de la table, au format SQL suivant
+ <command>quote_ident(nspname)
+ || '.' || quote_ident(relname)</command>.</para></listitem>
+ </varlistentry>
+ </variablelist>
+
+ <note><para>Pour le moment il existe des limitations; vous pouvez
+ créer une table &postgres; avec aucune colonne, par exemple
+ <command>create table table_vide ();</command>.
+ &slony1; refusera de manipuler une telle table.
+ Ce n'est pas vraiment une limitation gênante car il est
+ n'est pas très intéressant de répliquer des tables qui ne contiennent
+ aucune information.</para> </note>
+
+ <caution><para><command>TABLE ADD KEY</command> <emphasis>ne doit
+ pas être utilisée</emphasis> si vous pouvez vous en passer.
+ C'est un <emphasis>élément</emphasis> des &bestpracticelink;.</para>
+
+ <para>L'absence d'une clef primaire adéquate est
+ une indication très sérieuse que le schéma est
+ <emphasis>défectueux</emphasis>. La
+ <emphasis>bonne</emphasis> méthode pour le réparer est d'introduire
+ un clef primaire adéquate, et non pas de demander à &slony1; d'en <quote>bricoler</quote> une.</para>
+
+ <para>Cette commande n'est <emphasis>pas</emphasis> supportée par le &logshiplink;,
+ et nous n'avons pas l'intention de développer ce support.</para> </caution>
+
+ <para>Cette commande utilise &funtableaddkey;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ TABLE ADD KEY ( NODE ID = 1,
+ FULLY QUALIFIED NAME = 'public.history' );
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Sur le nœud origine, la commande posera un verrou exclusif
+ sur la table modifiée tant que ces opérations ne seront pas terminées :
+ </para>
+ <itemizedlist>
+ <listitem><para>Modifier la table, ajouter la colonne ;</para></listitem>
+ <listitem><para>Modifier chaque ligne de la table, attacher la valeur de la séquence ;</para></listitem>
+ <listitem><para>Ajouter un nouvel index unique à la table.</para></listitem>
+ </itemizedlist>
+
+ <para>Sur les nœuds abonnés, ces modifications sont
+ réalisées sur la table lorsqu'elle est TODO, et perturbe
+ pas particulièrement l'abonnement au cours du verrouillage
+ sur le nœud abonné.</para>
+
+ <para>Si la table est volumineuse et fréquemment mise à jour
+ par vos applications, cela imposera une coupure de service
+ significative qui correspond au temps de modification de la
+ table sur le nœud d'origine. C'est pourquoi il est recommandé
+ que cette commande ne soit pas utilisée quand c'est possible.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+
+<!-- **************************************** -->
+
+ <refentry id="stmtcreateset"><refmeta><refentrytitle>CREATE SET</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>CREATE SET</refname>
+
+ <refpurpose>Crée un ensemble de réplication &slony1;</refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>CREATE SET (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>
+ Dans le système de réplication &slony1;, les tables répliquées sont
+ regroupées en ensembles. En règle générale, un ensemble contient
+ des tables reliées pour une application donnée. Dans une application
+ correctement conçue, toutes ces tables sont regroupées dans un
+ schéma.
+ </para>
+ <para>
+ L'ensemble de réplication est la plus petite unité qu'un nœud peut répliquer vers un autre nœud.
+ Un ensemble de réplication a toujours une origine. En terme classique,
+ c'est ce qu'on appelle le <quote>maître</quote>.
+ Puisqu'avec &slony1; un nœud peut être simultanément <quote>maître</quote> pour un ensemble,
+ et tenir le rôle d'<quote>esclave</quote> pour un autre, cette terminologie peut
+ rapidement prêter à confusion et doit par conséquent être remplacée par
+ <quote>ensemble d'origine</quote> et <quote>abonné</quote>.
+ </para>
+
+ <variablelist>
+ <varlistentry><term><literal>ID = ival</literal></term>
+ <listitem><para>Identifiant de l'ensemble qu'il faut créer.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>ORIGIN = ival</literal></term>
+ <listitem><para>Nœud d'origine initial de cet ensemble.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>COMMENT = 'chaîne'</literal></term>
+ <listitem><para>Un texte descriptif peut être ajouté pour l'ensemble de réplication.</para>
+ <para>Si aucun commentaire n'est fourni, la valeur par défaut est <command>A replication set so boring no one thought to give it a name</command> (NdT : <quote>Un ensemble de réplication tellement
+ ennuyeux que personne n'a pensé à lui donner un nom</quote>)
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>Cette commande utilise &funstoreset;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ CREATE SET ( ID = 1,
+ ORIGIN = 1,
+ COMMENT = 'Tables du système de réservation' );
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ <para>Jusqu'à la version 1.2, la commande échoue si aucun commentaire n'est fourni.</para>
+ </refsect1>
+ </refentry>
+
+
+<!-- **************************************** -->
+
+ <refentry id="stmtdropset"><refmeta><refentrytitle>DROP SET</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>DROP SET</refname>
+
+ <refpurpose>Enlever un ensemble de réplication &slony1;</refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>DROP SET (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>
+ Supprime un ensemble de tables de la configuration &slony1;.
+ Cette commande désabonne automatiquement tous les nœuds qui
+ hébergent cet ensemble et rétablit les règles et les triggers
+ originaux sur tous les abonnés.
+ </para>
+
+ <variablelist>
+ <varlistentry><term><literal>ID = ival</literal></term>
+ <listitem><para>Identifiant de l'ensemble qu'il faut supprimer.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>ORIGIN = ival</literal></term>
+ <listitem><para>Nœud d'origine actuel de l'ensemble de réplication.</para></listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>Cette commande utilise &fundropset;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ DROP SET ( ID = 5,
+ ORIGIN = 2 );
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Sur chaque nœud, la commande pose un verrou exclusif sur
+ chaque table répliquée afin de modifier le schéma de la table
+ pour nettoyer les triggers et les règles.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtmergeset"><refmeta><refentrytitle>MERGE
+ SET</refentrytitle><manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>MERGE SET</refname>
+
+ <refpurpose>Fusionne plusieurs ensembles de réplication &slony1;</refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>MERGE SET (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Fusionne un ensemble de tables et de séquences dans un autre ensemble.
+ Cette fonction est un contournement face à l'impossibilité
+ d'ajouter des tables/séquences à des ensembles en cours de
+ réplication. On peut alors créer un ensemble temporaire, y ajouter
+ les nouveaux objets, abonner tous les nœuds à ce nouvel ensemble,
+ puis fusionner l'ensemble courant et l'ensemble temporaire, ce qui supprime
+ l'identifiant de l'ensemble temporaire.
+ </para>
+
+ <para>
+ Cette opération ne fonctionnera si les deux ensembles ne sont pas
+ répliqués <emphasis>exactement</emphasis> sur les mêmes nœuds abonnés.
+ </para>
+
+ <variablelist>
+ <varlistentry><term><literal>ID = ival</literal></term>
+ <listitem><para>Identifiant unique de l'ensemble qui contiendra les deux ensembles distincts.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>ADD ID = ival</literal></term>
+ <listitem><para>Identifiant unique de l'ensemble de l'ensemble dont les objets vont être transférés.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>ORIGIN = ival</literal></term>
+ <listitem><para>Nœud d'origine actuel des deux ensembles.</para></listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>Cette commande utilise &funmergeset;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ # Supposons que l'ensemble 1 est répliqué sur les nœuds 2 et 3
+ SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 2);
+ SYNC (ID=1);
+ WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 2, WAIT FOR=1);
+ SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 3);
+ SYNC (ID=1);
+ WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 3, WAIT FOR=1);
+ MERGE SET ( ID = 1, ADD ID = 999, ORIGIN = 1 );
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1><title>Comportement dangereux ou non-intuitif</title>
+
+ <para>La fusion se déroule suivant la configuration sur le nœud origine.
+ Si une fusion est demandée alors que les abonnements sont toujours
+ en cours de traitement, cela peut briser les réplications en cours
+ sur les nœuds abonnés car ils chercheront la configuration de cet
+ ensemble alors qu'il vient d'être supprimé. Ne soyez pas trop
+ rapide lorsque vous fusionnez des ensembles.
+ </para>
+
+ </refsect1>
+ <refsect1> <title>Note de version</title> <para>Cette commande
+ fut introduite dans &slony1; 1.0.5. Dans la version 1.2.1,
+ une condition de concurrence (« race condition ») a été corrigée.
+ Elle apparaissait lorsque la requête de fusion était soumise
+ alors que les demande d'abonnement étaient traitées.
+ Cela empêche les fusions avant que les abonnements ne soient
+ complètement réalisés.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtsetaddtable"><refmeta><refentrytitle>SET ADD TABLE</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>SET ADD TABLE</refname>
+
+ <refpurpose>Ajoute une table dans un ensemble de réplication &slony1;</refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>SET ADD TABLE (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Ajoute une table existante dans un ensemble de réplication. L'ensemble ne doit
+ pas être répliqué sur un autre nœud, cette fonctionnalité est assurée par la commande
+ <xref linkend="stmtmergeset"/>.
+
+ <variablelist>
+ <varlistentry><term><literal>SET ID = ival</literal></term>
+ <listitem><para>Identifiant de l'ensemble dans lequel la table doit être ajoutée.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>ORIGIN = ival</literal></term>
+ <listitem><para>Nœud origine de l'ensemble. Les prochaines versions de <application>slonik</application>
+ devraient pouvoir deviner cette information.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>ID = ival</literal></term>
+
+ <listitem><para>Identifiant unique de la table. Ces identifiants ne sont
+ pas seulement utilisés pour désigner une table dans l'ensemble de réplication.
+ Cette valeur numérique détermine également l'ordre de verrouillage des tables,
+ notamment lors de la commande <xref linkend="stmtlockset"/>.
+ Cet identifiant doit donc suivre une certaine hiérarchie afin que les scripts
+ <application>slonik</application> ne provoquent de situation d'inter-blocage (« deadlocks »).
+ </para>
+
+ <para>Cet identifiant doit être unique pour tous les ensembles de réplication ;
+ vous ne devez pas avoir deux tables du même cluster avec le même identifiant.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>FULLY QUALIFIED NAME = 'string'</literal></term>
+ <listitem><para>Le nom complet de la table tel que décrit dans
+ <xref linkend="stmttableaddkey"/>.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>KEY = { 'string' | SERIAL }</literal></term> <listitem><para>
+ <emphasis>(Facultatif)</emphasis> Le nom de l'index relatif à la colonne unique et
+ NOT NULL qui est utilisée comme identifiant de ligne lors de la réplication.
+ Si le mot-clef SERIAL est utilisé, cela indique qu'il faut utiliser la colonne
+ spéciale ajoutée avec la commande <xref linkend="stmttableaddkey"/>.
+ Par défaut, on utilise la clef primaire de la table. Le nom de l'index n'est
+ <emphasis>pas</emphasis> un nom complet ; vous devez omettre le schéma.</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>COMMENT = 'string'</literal></term>
+ <listitem><para>Un texte décrivant la table.</para></listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ <para>Cette commande utilise &funsetaddtable;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+SET ADD TABLE (
+ SET ID = 1,
+ ORIGIN = 1,
+ ID = 20,
+ FULLY QUALIFIED NAME = 'public.tracker_ticket',
+ COMMENT = 'Ticket de Support'
+);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Messages d'erreur</title>
+
+ <para>Voici quelque messages d'erreurs que vous rencontrerez en cas d'utilisation incorrecte :</para>
+
+ <variablelist>
+ <varlistentry><term><literal>Slony-I: setAddTable_int: table public.ma_table PK column id nullable</literal></term>
+
+ <listitem><para>Les clefs primaires (ou les clefs candidates) doivent être composées
+ de colonnes <command>NOT NULL</command>. Si vous avez une clef primaire candidate dont une
+ colonne n'est pas déclarée ainsi, alors &slony1; rejettera la table et produira ce message.</para>
+ </listitem> </varlistentry>
+
+ <varlistentry><term><literal>Slony-I: setAddTable_int: table id 14 has already been assigned!</literal></term>
+
+ <listitem><para>L'identifiant de la table, stocké dans
+ <envar>sl_table.tab_id</envar>, doit être unique pour tous les nœuds/tables/ensembles.
+ Ce message indique que vous avez tenté de déclarer un identifiant qui est déjà utilisé.
+ </para> </listitem> </varlistentry>
+
+ <varlistentry><term><literal>Slony-I: setAddTable_int(): table public.ma_table has no index mt_idx_14</literal></term>
+
+ <listitem><para>Ceci se produit en général avec les clefs primaires candidates ;
+ le message indique que l'index spécifié n'est pas disponible sur ce nœud.
+ </para> </listitem> </varlistentry>
+
+ <varlistentry><term><literal>Slony-I: setAddTable_int(): table public.ma_table not found</literal></term>
+
+ <listitem><para>Pire que l'absence d'un index, c'est la table qui est manquante.
+ Le message indique que le processus que vous avez utilisé pour mettre en place le schéma n'a pas
+ fonctionné correctement.</para>
+ </listitem> </varlistentry>
+
+ <varlistentry><term><literal>Slony-I: setAddTable_int(): public.ma_vue is not a regular table</literal></term>
+
+ <listitem><para>Vous ne pouvez répliquer que des tables (en tout cas avec
+ <command>SET ADD TABLE</command>). Cela n'inclut pas les vues et les index
+ (les index sont répliqués de facto, mais on peut pas demander explicitement la réplication d'un index).
+ </para> </listitem> </varlistentry>
+
+ <varlistentry><term><literal>Slony-I: setAddTable_int(): set 4 not found</literal></term>
+
+ <listitem><para>Vous devez défini l'ensemble de réplication avant de lui assigner des tables.
+ </para> </listitem> </varlistentry>
+
+ <varlistentry><term><literal>Slony-I: setAddTable(): set 4 has remote origin</literal></term>
+
+ <listitem><para>Ceci se produit lorsque l'ensemble de réplication #4 est configuré
+ sur une origine, le nœud 1, et que vous lancez une commande <command>SET ADD
+ TABLE</command> qui spécifie un autre nœud que le nœud 1. Ceci se produit généralement
+ lorsque la configuration <command>admin conninfo</command> est confuse à l'intérieur du
+ préambule du script slonik...</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry><term><literal>Slony-I: cannot add table to currently subscribed set 1</literal></term>
+
+ <listitem><para>&slony1; ne peut pas ajouter des tables dans un ensemble qui est
+ en cours de réplication. Pour contourner ce problème, vous devez définir un nouvel ensemble
+ qui contiendra les nouvelles tables.</para> </listitem> </varlistentry>
+
+ </variablelist>
+
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Sur le nœud origine, cette opération demande un verrou exclusif très bref sur la table
+ afin de lui ajouter les triggers de réplication. Sur les nœuds abonnés, les verrous
+ correspondant sont réalisés au moment de l'événement <command>SUBSCRIBE_SET</command>.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtsetaddsequence"><refmeta><refentrytitle>SET ADD SEQUENCE</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>SET ADD SEQUENCE</refname>
+
+ <refpurpose>Ajoute une séquence dans un ensemble de réplication</refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>SET ADD SEQUENCE (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+<refsect1>
+ <title>Description</title>
+
+ <para>
+ Ajoute une séquence existante dans un ensemble de réplication. L'ensemble ne
+ doit pas être répliqué sur un autre nœud. Cette fonctionnalité est supportée
+ par la commande <xref linkend="stmtmergeset"/>.
+
+ <variablelist>
+ <varlistentry><term><literal>SET ID = ival</literal></term>
+ <listitem><para>Identifiant de l'ensemble dans lequel on ajoute la séquence.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>ORIGIN = ival</literal></term>
+ <listitem><para>Nœud d'origine de l'ensemble. Les prochaines version de <application>slonik</application>
+ devraient pouvoir deviner cette information.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>ID = ival</literal></term>
+
+ <listitem><para>Identifiant unique de la séquence.
+ <note><para> Notons
+ que cet identifiant doit être unique parmi <emphasis>toutes les séquences</emphasis>
+ du cluster ; la numérotation des tables est indépendante, donc il est possible
+ de donner l'identifiant 20 à une table et à une séquence, sans que cela ne crée de confusion.
+ </para> </note></para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>FULLY QUALIFIED NAME = 'string'</literal></term>
+ <listitem><para>Le nom complet de la séquence telle que décrit dans
+ <xref linkend="stmttableaddkey"/>.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>COMMENT = 'string'</literal></term>
+ <listitem><para>Un texte décrivant la séquence.</para></listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ <para>Cette commande utilise la fonction &funsetaddsequence;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ SET ADD SEQUENCE (
+ SET ID = 1,
+ ORIGIN = 1,
+ ID = 20,
+ FULLY QUALIFIED NAME = 'public.tracker_ticket_id_seq',
+ COMMENT = 'Séquence d'identifiants des tickets de support'
+ );
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtsetdroptable"><refmeta><refentrytitle>SET DROP TABLE</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>SET DROP TABLE</refname>
+
+ <refpurpose>Supprime une table d'un ensemble de réplication &slony1;
+ </refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>SET DROP TABLE (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>
+ Supprime une table d'un ensemble de réplication.
+ </para>
+ <para>
+ Notez que cette action ne supprimera <emphasis>pas</emphasis> une clef primaire
+ candidate créée avec la commande <xref linkend="stmttableaddkey"/>.
+
+ <variablelist>
+ <varlistentry><term><literal>ORIGIN = ival</literal></term>
+ <listitem><para>Nœud d'origine de l'ensemble de réplication.
+ Les prochaines versions de <application>slonik</application>
+ devraient pouvoir deviner cette information.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>ID = ival</literal></term>
+
+ <listitem><para>Identifiant unique de la table.</para></listitem></varlistentry>
+ </variablelist>
+ </para>
+ <para>Cette commande utilise la fonction &funsetdroptable;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ SET DROP TABLE (
+ ORIGIN = 1,
+ ID = 20
+ );
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Cette opération pose un verrou exclusif sur la table qui est supprimée afin
+ de retirer les triggers de réplication. Sur les nœuds abonnées, cela implique également
+ le rétablissement des règles et des triggers qui ont été désactivés.
+ </para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.5.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtsetdropsequence"><refmeta><refentrytitle>SET DROP SEQUENCE</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>SET DROP SEQUENCE</refname>
+
+ <refpurpose>Supprime une séquence d'un ensemble de réplication &slony1;
+ </refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>SET DROP SEQUENCE (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>
+ Supprime une séquence existante dans un ensemble de réplication.
+ <variablelist>
+ <varlistentry><term><literal>ORIGIN = ival</literal></term>
+ <listitem><para>Nœud d'origine de l'ensemble. Les prochaines versions de <application>slonik</application>
+ devraient pouvoir deviner cette information.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>ID = ival</literal></term>
+
+ <listitem><para>Identifiant unique de la séquence.</para></listitem>
+
+ </varlistentry>
+ </variablelist>
+ </para>
+ <para>Cette commande utilise la fonction &funsetdropsequence;.</para>
+ </refsect1>
+<refsect1><title>Exemple</title>
+ <programlisting>
+ SET DROP SEQUENCE (
+ ORIGIN = 1,
+ ID = 20,
+ );
+</programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.5.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtsetmovetable"><refmeta><refentrytitle>SET MOVE
+ TABLE</refentrytitle><manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>SET MOVE TABLE</refname>
+
+ <refpurpose>Déplace une table d'un ensemble de réplication vers un autre.
+ </refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>SET MOVE TABLE (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>
+ Change l'ensemble de réplication dans lequel se trouve la table. L'ensemble courant et le
+ nouveau doivent avoir le même nœud origine et les même nœuds abonnés.
+
+ <caution><para>La méthode d'abonnement d'un nouvel ensemble de réplication est
+ particulière.Vous devez vous assurer que l'abonnement est complètement effectué sur tous les nœuds
+ avant de déplacer les tables. Déplacer une table trop tôt vers un nouvel ensemble
+ implique que le nœud abonné va essayer d'ajouter la table pendant le processus d'abonnement
+ de l'ensemble de réplication, ce qui échoue suite à une erreur de clef dupliquée et provoque
+ l'arrêt de la réplication.</para></caution>
+
+ <variablelist>
+ <varlistentry><term><literal>ORIGIN = ival</literal></term>
+ <listitem><para>Origine actuelle de l'ensemble. Les prochaines versions de <application>slonik</application>
+ devraient pouvoir deviner cette information.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>ID = ival</literal></term>
+
+ <listitem><para>Identifiant unique de la table.</para></listitem></varlistentry>
+ <varlistentry><term><literal>NEW SET = ival</literal></term>
+
+ <listitem><para>Identifiant unique de l'ensemble dans lequel il faut ajouter la table.</para></listitem></varlistentry>
+ </variablelist>
+ </para>
+ <para>Cette commande utilise la fonction &funsetmovetable;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+SET MOVE TABLE (
+ ORIGIN = 1,
+ ID = 20,
+ NEW SET = 3
+);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.5.</para>
+ </refsect1>
+</refentry>
+
+
+<!-- **************************************** -->
+
+ <refentry id="stmtsetmovesequence"><refmeta><refentrytitle>SET MOVE SEQUENCE</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>SET MOVE SEQUENCE</refname>
+
+ <refpurpose>Déplace une séquence d'un ensemble de réplication &slony1; vers un autre.
+ </refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>SET MOVE SEQUENCE (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>
+ Change l'ensemble de réplication dans lequel se trouve la séquence.
+ L'ensemble courant et le nouveau doivent avoir le même nœud d'origine
+ et les mêmes nœuds abonnés.
+
+ <caution><para>La méthode d'abonnement à un nouvel ensemble est particulière.
+ Vous devez vous assurer que l'abonnement est complètement effectué
+ avant de déplacer les séquences. Déplacer une séquence top tôt peut impliquer
+ une tentative d'ajout de la séquence pendant le processus d'abonnement,
+ ce qui échouera en émettant une erreur à cause d'une clef dupliquée et
+ provoquera l'arrêt de la réplication.</para></caution>
+
+ <variablelist>
+ <varlistentry><term><literal>ORIGIN = ival</literal></term>
+ <listitem><para>Nœud d'origine de l'ensemble de réplication. Les
+ futures versions de <application>slonik</application> devraient
+ deviner toutes seules cette information.</para></listitem>
+ </varlistentry>
+ <varlistentry><term><literal>ID = ival</literal></term>
+
+ <listitem><para>Identifiant unique de la séquence.</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>NEW SET = ival</literal></term>
+
+ <listitem><para>Identifiant unique de l'ensemble de réplication dans lequel
+ la séquence doit être déplacée.</para></listitem>
+
+ </varlistentry>
+ </variablelist>
+ </para>
+ <para>Cette commande utilise &funsetmovesequence;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+SET MOVE SEQUENCE (
+ ORIGIN = 1,
+ ID = 20,
+ NEW SET = 3
+);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.5.</para>
+ </refsect1>
+ </refentry>
+
+
+<!-- **************************************** -->
+
+ <refentry id="stmtstoretrigger"><refmeta><refentrytitle>STORE TRIGGER</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>STORE TRIGGER</refname>
+
+ <refpurpose>Indique qu'un trigger ne doit pas être désactivé par &slony1;
+sur un nœud abonné.
+ </refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>STORE TRIGGER (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Par défaut, tous les triggers définis par l'utilisateur sont
+désactivés sur tout les nœuds abonnés lorsque la table est répliquée.
+Cette commande peut être utilisée pour empêcher explicitement la désactivation
+d'un trigger.
+ <variablelist>
+ <varlistentry><term><literal>TABLE ID = ival</literal></term>
+ <listitem><para> L'identifiant numérique et unique de la table concernée par le trigger.</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>TRIGGER NAME = 'string'</literal></term>
+
+ <listitem><para>Le nom du trigger tel qu'on le trouve dans le catalogue système
+ <envar>pg_trigger</envar>.</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>EVENT NODE = ival</literal></term>
+
+ <listitem><para>(Optionnel) L'identifiant du nœud utilisé pour
+créer l'événement de configuration qui annonce aux nœuds existants la
+présence d'un trigger spécial. Par défaut, cette valeur est 1.
+ </para></listitem>
+
+ </varlistentry>
+ </variablelist>
+ </para>
+ <para>Cette commande utilise &funstoretrigger;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+STORE TRIGGER (
+ TABLE ID = 2,
+ TRIGGER NAME = 'cache_invalidation'
+);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Cette opération pose brièvement un verrou exclusif sur la table spécifiée
+sur chaque nœud auquel elle s'applique, afin de modifier le schéma de la table
+et y ajouter de nouveau le trigger.
+ </para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtdroptrigger"><refmeta><refentrytitle>DROP TRIGGER</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>DROP TRIGGER</refname>
+
+ <refpurpose>Cette commande redonne à un trigger son comportement par défaut :
+c'est-à-dire qu'il ne se déclenche pas sur les nœuds abonnés.</refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>DROP TRIGGER (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Supprime la gestion particulière du trigger spécifié.
+ <variablelist>
+ <varlistentry>
+ <term><literal>TABLE ID = ival</literal></term>
+ <listitem>
+ <para>L'identifiant numérique et unique de la table pour laquelle le
+ trigger est défini.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>TRIGGER NAME = 'string'</literal></term>
+ <listitem><para>Le nom du trigger tel qu'on le trouve dans le catalogue système
+ <envar>pg_trigger</envar>.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>EVENT NODE = ival</literal></term>
+ <listitem>
+ <para>(Optionnel) L'identifiant du nœud utilisé pour
+ créer l'événement de configuration qui annonce aux nœuds existants la
+ présence d'un trigger spécial. Par défaut, cette valeur est 1.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ <para>Cette commande utilise &fundroptrigger;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+DROP TRIGGER (
+ TABLE ID = 2,
+ TRIGGER NAME = 'cache_invalidation'
+);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Cette opération pose brièvement un verrou exclusif sur la table spécifiée
+sur chaque nœud auquel elle s'applique, afin de modifier le schéma de la table
+et y ajouter de nouveau le trigger.
+ </para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+ <refentry id="stmtsubscribeset"><refmeta><refentrytitle>SUBSCRIBE SET</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>SUBSCRIBE SET</refname>
+
+ <refpurpose>Lance la réplication d'un ensemble donné</refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>SUBSCRIBE SET (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Cette commande réalise une des deux opérations suivantes :</para>
+
+ <itemizedlist>
+
+ <listitem><para>Initie la réplication pour un ensemble de réplication.</para>
+ <para>Ceci déclenche la réplication sur un nœud (abonné) soit à partir
+de l'origine soit à partir du fournisseur, qui doit être lui-même un nœud
+abonné actif et transmetteur (« forwarding subscriber »).</para>
+
+ <para>Les tables de l'application contenues dans l'ensemble de réplication
+doivent déjà exister et, idéalement, elles sont vides. La version courante de
+&slony1; ne tente <emphasis>pas</emphasis> de copier le schéma de l'ensemble
+de réplication. Le démon de réplication démarre et commence à copier le contenu
+de l'ensemble de réplication à partir du fournisseur spécifié, puis essaie
+de rattraper son retard en rejouant les mises à jour qui se sont produites
+lors du processus de copie. Un fois que l'abonnement a réussi, les tables
+sont protégées avec des triggers contre les mises à jour en provenance de
+l'application.
+ </para>
+
+ <para>Si les tables sur l'abonné ne sont
+ <emphasis>pas</emphasis> vides, alors l'événement <command>COPY
+ SET</command> (qui fait partie du processus d'abonnement)
+ devra effectuer quelques taches supplémentaires :</para>
+ <itemizedlist>
+
+ <listitem><para>Il tente d'effectuer une <command>TRUNCATE</command>
+ sur la table, ce qui devrait être efficace.</para> </listitem>
+
+ <listitem><para>Si cela ne fonctionne pas (une relation sur une
+clef étrangère empêche peut-être le fonctionnement de TRUNCATE), il
+utilise la commande <command>DELETE</command> pour effacer toutes les
+<quote>anciennes</quote>
+entrées de la table.</para></listitem>
+
+ <listitem><para>Ces anciennes données encombrent encore l'espace
+disque jusqu'à ce qu'un <command>VACUUM</command> soit effectué <emphasis>après</emphasis>
+la fin du processus d'abonnement.</para></listitem>
+
+ <listitem><para>Les index de la table contiendront des références
+aux anciennes données, ce qui ralentira l'insertion de nouvelles données
+dans les index.</para></listitem>
+ </itemizedlist>
+
+ <warning><para>Le temps d'exécution de cette opération n'est pas
+négligeable. Si vous avez un grand volume de données dans un ensemble
+particulier de tables, cela peut prendre plusieurs heures, voire plusieurs
+jours pour que l'opération aboutisse (ici <quote>un grand volume</quote>
+signifie <quote>des dizaines ou des centaines de gigaoctets de données</quote>).</para>
+
+ <para>Cependant, la requête <command>SUBSCRIBE SET</command> se terminera
+presque immédiatement, même si les travaux, gérés par l'événement
+<command>COPY SET</command>, sont encore en cours. Si vous devez configurer
+les abonnements sur des nœuds en cascade, vous devez attendre que chaque
+abonné ait terminé son abonnement avant de soumettre des requête d'abonnement
+qui utilisent ce nœud comme fournisseur. Si vous ne le faites pas, ce n'est pas
+très grave : <command>slonik</command> va vérifier le nœud, découvrir qu'il
+n'est pas encore un fournisseur actif et reporter l'erreur suivante :
+</para>
+
+<programlisting>
+ Slony-I: provider 2 is not an active forwarding node for replication set 1
+</programlisting>
+
+ <para>En pratique, de telles requêtes d'abonnement seront ignorées
+jusqu'à ce que le fournisseur soit prêt.</para>
+</warning>
+
+ </listitem>
+
+ <listitem><para>Modifier les informations d'abonnement pour les
+nœuds qui sont déjà abonnés.</para>
+
+ <para>Si vous devez modifier les informations d'abonnement pour un
+nœud donné, vous devez <emphasis>également</emphasis> soumettre les
+nouvelles informations avec cette commande, et la nouvelle configuration sera
+propagée à travers le réseau de réplication. En général, on modifie
+les informations d'abonnement lorsqu'on veut abonner un nœud à un fournisseur
+<emphasis>différent</emphasis> ou transformer un nœud en <quote>transmetteur</quote>
+afin qu'il puisse à son tour devenir le fournisseur d'un autre abonné.
+</para>
+
+ </listitem>
+ </itemizedlist>
+
+ <variablelist>
+ <varlistentry><term><literal>ID = ival</literal></term>
+ <listitem><para>Identifiant de l'ensemble auquel on s'abonne</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>PROVIDER = ival</literal></term>
+
+ <listitem><para>Identifiant du nœud fournisseur qui transmet les données
+à ce nœud</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>RECEIVER = ival</literal></term>
+
+ <listitem><para>Identifiant du nouveau nœud abonné</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>FORWARD = boolean</literal></term>
+
+ <listitem><para>Indique si le nouvel abonné doit stocker les logs
+pendant la réplication afin de pouvoir devenir fournisseur pour de futurs
+nœuds.</para></listitem>
+
+ </varlistentry>
+ </variablelist>
+ <para>Cette commande utilise &funsubscribeset;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+SUBSCRIBE SET (
+ ID = 1,
+ PROVIDER = 1,
+ RECEIVER = 3,
+ FORWARD = YES
+);
+ </programlisting>
+ </refsect1>
+
+ <refsect1> <title>Transmission</title>
+
+ <para>Le paramètre <command>FORWARD=boolean</command> indique si le
+l'abonné doit conserver les informations dans les tables &sllog1; et &sllog2;.
+Ceci implique plusieurs choses...</para>
+
+ <para>Stocker les données dans ces tables sur l'abonné représente
+une charge supplémentaire. Si vous êtes certain(e) que vous n'effectuerez
+jamais les opérations <xref linkend="stmtmoveset"/> ou <xref
+linkend="stmtfailover"/> sur un abonné particulier, il vaut mieux
+désactiver la transmission sur ce nœud.</para>
+
+ <para>Cela étant dit, dans certains cas, le fait de désactiver cette option
+peut poser des problèmes lorsqu'on se trouve dans une situation inattendue.
+De manière empirique, on considère qu'il est préférable que <emphasis>tout
+nœud connecté directement à l'origine</emphasis> soit
+un <quote>nœud transmetteur </quote>. Il est possible que ce nœud
+soit perdu lors d'une bascule d'urgence. Le problème survient lorsque
+ce nœud est en avance sur les autres nœuds.</para>
+
+ <para>Supposons que l'origine, le nœud 1, est au numéro de SYNC
+88901, un nœud non-transmetteur, le nœud 2 en est arrivé au numéro
+88897, tandis que les autres nœuds transmetteur, 3, 4, et 5, en sont
+seulement au SYNC numéro 88895. À ce moment, le disque système sur le
+nœud origine prend feu. Le nœud 2 possède les <emphasis>données</emphasis> à jour
+jusqu'à 88901, mais aucun nœud transmetteur ne dispose, dans les tables
+&sllog1; ou &sllog2;, des données correspondant
+aux événements SYNCs numérotés 88896 et 88897. Il n'y a donc
+aucun moyen de ramener les nœuds 3-5 à ce niveau.</para>
+
+ <para>À ce stade, vous avez deux choix : supprimer le nœud2 car il
+n'existe aucun moyen de le maintenir, ou supprimer tous les nœuds
+<emphasis>sauf</emphasis> le nœud 2, car il n'existe aucun moyen de les
+amener jusqu'à l'événement SYNC 88897.</para>
+
+ <para>Ce dilemme peut être évité en s'assurant que tous les nœuds directement
+abonnés à l'origine sont des transmetteurs.</para>
+
+ </refsect1>
+ <refsect1> <title>Comportement dangereux et non-intuitif</title>
+
+ <itemizedlist>
+
+ <listitem><para>Le fait que la requête se termine immédiatement
+même si l'abonnement prend un temps considérable est parfois surprenant.
+ </para>
+
+ <para>Le traitement des abonnements implique
+ <emphasis>deux</emphasis> événements ; l'opération
+ <command>SUBSCRIBE_SET</command>, initié sur le nœud fournisseur,
+et une opération <command>ENABLE_SUBSCRIPTION</command>, qui est
+initiée sur le nœud abonné. Cela signifie que <xref
+ linkend="stmtwaitevent"/> ne peut pas attendre la fin d'une souscription.
+Si vous souhaitez attendre la fin d'un abonnement, alors vous devez soumettre une
+requête <xref linkend="stmtsync"/> et attendre que <emphasis>cet</emphasis> événement
+s'achève.</para>
+ </listitem>
+
+ <listitem><para> Cette commande a <emphasis>deux</emphasis>
+objectifs : mettre en place des abonnements (ce qui n'est très surprenant)
+et <emphasis>modifier des abonnements</emphasis>, ce qui n'est pas forcément
+intuitif.</para> </listitem>
+
+ <listitem><para>Les nouveaux abonnements sont définis en utilisant
+<command>DELETE</command> ou <command>TRUNCATE</command> pour vider
+les tables sur l'abonné. Si vous avez créé un nouveau nœud en
+recopiant les données à partir d'un nœud existant, il peut <quote>paraître
+évident</quote> que ces données seront conservées. Ce n'est pas le cas,
+l'ancien contenu est détruit et le nœud est re-peupler <emphasis>à partir
+de zéro</emphasis>.</para> </listitem>
+
+ </itemizedlist>
+
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Cette opération ne nécessite <emphasis>pas</emphasis> de verrous
+sur le nœud fournisseur.</para>
+
+ <para>Sur le nœud abonné, l'opération placera un verrou
+sur toutes les table de l'ensemble de réplication. Dans la version
+1.2, les verrous exclusifs sont placés au début du processus ; dans les
+versions antérieures, les verrous sont placés implicitement uniquement lorsque
+qu'une activité le demande, ce qui laisse une possibilité d'inter-blocage
+(« deadlock ») si d'autres applications peuvent accéder à la base à ce moment-là.
+ </para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtunsubscribeset"><refmeta><refentrytitle>UNSUBSCRIBE SET</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>UNSUBSCRIBE SET</refname>
+
+ <refpurpose>Arrête la réplication d'un ensemble de réplication &slony1;</refpurpose></refnamediv>
+
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>UNSUBSCRIBE SET (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Cette commande interrompt la réplication d'un ensemble sur un abonné.
+Les tables sont alors ouvertes en accès total aux applications clientes sur l'ancien
+abonné. Les tables ne sont ni détruites ni modifiées. Tous les triggers originaux, les règles
+et les contraintes sont restaurées.
+
+ <variablelist>
+ <varlistentry><term><literal> ID = ival</literal></term>
+ <listitem><para>Identifiant de l'ensemble à désabonner</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>RECEIVER = ival</literal></term>
+
+ <listitem><para>Identifiant du nœud de l' (ancien) abonné</para></listitem>
+
+ </varlistentry>
+ </variablelist>
+ </para>
+ <para>Cette commande utilise &fununsubscribeset;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+UNSUBSCRIBE SET (
+ ID = 1,
+ RECEIVER = 3
+);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Des verrous exclusifs sont posés sur chaque table répliquée
+de l'abonné afin de supprimer les triggers de réplication et de restaurer
+les anciens triggers/règles.</para>
+ </refsect1>
+
+ <refsect1><title>Comportement dangereux et non-intuitif</title>
+
+ <para>Ré-abonner un ensemble désabonné nécessite une
+ <emphasis>copie fraîche et complète</emphasis> des données obtenue à partir
+du nœud fournisseur car les tables ont pu être soumises à des modifications
+indépendantes.</para>
+
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+
+<!-- **************************************** -->
+
+ <refentry id ="stmtlockset"><refmeta><refentrytitle>LOCK SET</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>LOCK SET</refname>
+
+ <refpurpose>Protège un ensemble de réplication &slony1; pour le
+préparer à un <command>MOVE SET</command></refpurpose></refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>LOCK SET (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Cette commande protège un ensemble de réplication des mises à
+jour en provenance des applications clientes, en préparation d'une
+commande <xref linkend="stmtmoveset"/>.
+ </para>
+
+ <para>Cette commande doit être la première dans un groupe de commande <command>try</command>.
+En effet, il faut <quote>committer</quote> les changements faits sur les tables
+ (ajout d'une fonction trigger spéciale) avant d'attendre que toutes les
+transactions concurrentes se termine. En même temps, il ne faut pas
+non plus garder une transaction ouverte sur la base elle-même car cela
+cela signifierait qu'elle se bloque elle-même.
+ </para>
+
+ <para>Notons qu'il s'agit d'une opération &rlocking;, ce qui signifie qu'elle peut être
+bloqué derrière d'autres activités de la base.</para>
+
+ <para>L'opération attend que les identifiants de transaction avancent
+afin qu'aucune donnée ne soit oubliée sur la nouvelle origine. Ainsi,
+si vous avez des transactions très longues en cours sur le nœud source,
+cette opération attendra que ces transactions aboutissent.
+Malheureusement, si vous avez une autre base de données sur le même
+ postmaster du nœud origine, les transactions longues en cours
+sur cette base seront aussi prises en compte même si elles sont par définition
+indépendantes.
+
+ <variablelist>
+ <varlistentry><term><literal>ID = ival</literal></term>
+ <listitem><para>Identifiant de l'ensemble à bloquer</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>ORIGIN = ival</literal></term>
+
+ <listitem><para>Identifiant du nœud de l'ensemble d'origine</para></listitem>
+
+ </varlistentry>
+ </variablelist>
+ </para>
+ <para>Cette commande utilise &funlockset;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+LOCK SET (
+ ID = 1,
+ ORIGIN = 3
+);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Des verrous exclusifs sont posés sur chaque table répliquée sur le nœud origine
+ et des triggers qui rejettent les mises à jour sont ajoutés su chacune de ces tables.
+ </para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtunlockset"><refmeta><refentrytitle>UNLOCK SET</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>UNLOCK SET</refname>
+
+ <refpurpose>Déverrouille un ensemble &slony1; qui est bloqué</refpurpose></refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>UNLOCK SET (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>
+ Cette commande déverrouille un ensemble préalablement verrouillé.
+
+ <variablelist>
+ <varlistentry><term><literal>ID = ival</literal></term>
+ <listitem><para>Identifiant de l'ensemble à déverrouiller</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>ORIGIN = ival</literal></term>
+
+ <listitem><para>Identifiant du nœud origine de l'ensemble</para></listitem>
+
+ </varlistentry>
+ </variablelist>
+ </para>
+ <para>Cette commande utilise &fununlockset;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+UNLOCK SET (
+ ID = 1,
+ ORIGIN = 3
+);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Des verrous exclusifs sont placés sur chaque table répliquée sur le nœud origine
+ car les triggers qui rejetent les mises à jour sont retirés de chacune des tables.
+ </para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+
+<!-- **************************************** -->
+
+ <refentry id="stmtmoveset"><refmeta><refentrytitle>MOVE SET</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>MOVE SET</refname>
+
+ <refpurpose>Change l'origine d'un ensemble de réplication &slony1;
+ </refpurpose></refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>MOVE SET (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Cette commande déplace l'origine d'un ensemble de réplication d'un nœud
+ vers un autre. La nouvelle origine doit être un abonné de cet ensemble. L'ensemble
+ doit être verrouillé sur l'ancien nœud origine.
+ </para>
+
+ <para>Après cette commande, l'ensemble ne peut plus être déverrouillé sur
+ l'ancienne origine. Celle-ci va continuer comme un nœud transmetteur
+ de l'ensemble et la chaîne d'abonnement entre l'ancienne et la nouvelle origine
+ sera inversée. Dès que la nouvelle origine a terminé le traitement de l'événement
+ (ce qui inclue tous les événements SYNC qui se sont produit avant la commande),
+ elle prend le contrôle et ouvre toutes les tables de l'ensemble de réplication
+ aux mises à jour en provenance de l'application.
+ </para>
+
+ <para>Ceci n'est <emphasis>pas</emphasis> une bascule d'urgence car cela nécessite
+ que l'ancienne origine fonctionne correctement (vous devez verrouiller l'ensemble
+ de réplication sur l'ancienne origine). Il est préférable d'utiliser
+ <command>MOVE SET</command> au lieu de <command>FAILOVER</command> si c'est possible
+ car la commande <command>FAILOVER</command> transforme le nœud origine en un
+ nœud corrompu. Avant d'effectuer un <command>MOVE SET</command>, il faut lancer la
+ commande <command>LOCK SET</command>.
+</para>
+
+ <para>Notez qu'il s'agit d'une opération &rlocking;, ce qui signifie qu'elle peut être bloquée
+ derrière l'activité des autres bases.
+
+ <variablelist>
+ <varlistentry><term><literal>ID = ival</literal></term>
+ <listitem><para>Identifiant de l'ensemble à transférer</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>OLD ORIGIN = ival</literal></term>
+
+ <listitem><para>Identifiant du nœud origine actuel</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>NEW ORIGIN = ival</literal></term>
+
+ <listitem><para>Identifiant du futur nœud origine</para></listitem>
+
+ </varlistentry>
+ </variablelist>
+ </para>
+ <para>Cette commande utilise &funmoveset;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+LOCK SET (
+ ID = 1,
+ ORIGIN = 1
+);
+MOVE SET (
+ ID = 1,
+ OLD ORIGIN = 1,
+ NEW ORIGIN = 3
+);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Des verrous exclusifs sont posés sur chaque table répliquée,
+à la fois sur l'ancien nœud origine et le nouveau nœud origine, car
+les triggers de réplication sont changés sur les deux nœuds :
+sur l'ancienne origine, chaque table supprime deux triggers
+(logtrigger et lockset) et ajoute un trigger denyaccess ;
+sur la nouvelle origine, le trigger denyaccess est supprimé et
+le trigger logtrigger est ajouté.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtfailover"><refmeta><refentrytitle>FAILOVER</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>FAILOVER</refname>
+
+ <refpurpose>Cette commande bascule un ensemble de réplication
+en échec vers un nœud de secours.
+ </refpurpose></refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>FAILOVER (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>
+ La commande <command>FAILOVER</command> transfert tous les ensembles dont
+l'origine est en panne vers le nœud de secours.
+ <application>slonik</application> va contacter tous les autres nœuds directement
+abonnés au nœud en panne pour déterminer le nœud qui a le meilleur niveau de synchronisation
+pour chacun des ensembles de réplication. Si un autre nœud a un niveau de synchronisation
+plus élevé que le nœud de secours, la réplication sera d'abord redirigée pour que le nœud
+de secours rattrape son retard sur l'autre nœud, puis pour qu'il assume le rôle d'origine
+et reçoive les mises à jour.
+ </para>
+
+ <para>
+ Après une bascule d'urgence réussie, tous les anciens nœuds abonnés directement
+au nœud en panne deviennent des abonnés direct du nœud de secours.
+Le nœud en panne est abandonné et doit être retiré de la configuration avec
+<xref linkend="stmtdropnode"/>.
+ </para>
+
+ <variablelist>
+ <varlistentry><term><literal>ID = ival</literal></term>
+ <listitem><para>Identifiant du nœud en panne</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>BACKUP NODE = ival</literal></term>
+
+ <listitem><para>Identifiant du nœud de secours qui va prendre en charge
+les ensembles de réplication dont l'origine est le nœud en panne</para></listitem>
+
+ </varlistentry>
+ </variablelist>
+
+ <para>Cette commande utilise &funfailednode;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+FAILOVER (
+ ID = 1,
+ BACKUP NODE = 2
+);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Des verrous exclusifs sont posés sur chaque table répliquée sur
+le nouveau nœud origine car les triggers de réplication sont changés.
+Si la nouvelle origine n'est pas tout à fait à jour et que des données
+doivent être rapatriées depuis à partir d'un autre nœud qui est mieux synchronisé,
+alors la nouvelle origine ne sera pas utilisable avant que ces mises à jour
+soient terminées.
+ </para>
+ </refsect1>
+ <refsect1><title>Comportement dangereux et non-intuitif</title>
+ <para>Cette commande va abandonner le nœud en panne.
+Il n'y a pas de possibilité de réintégrer le nœud en panne
+sans le reconstruire à partir de zéro en tant qu'esclave.
+Si c'est possible, il est préférable d'utiliser la commande
+ <xref linkend="stmtmoveset"/> car elle n'abandonne
+ <emphasis>pas</emphasis> le nœud en panne.
+ </para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtddlscript"><refmeta><refentrytitle>EXECUTE SCRIPT</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>EXECUTE SCRIPT</refname>
+
+ <refpurpose>Exécute un script SQL/DDL</refpurpose></refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>EXECUTE SCRIPT (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>Cette commande exécute un script contenant des ordres SQL sur
+ tous les nœuds qui sont abonnés à un ensemble de réplication à un
+ point précis dans le flux des transactions.</para>
+
+ <para>L'origine de l'événement doit être l'origine de l'ensemble
+de réplication. Le fichier de script ne doit pas contenir d'ordres
+<command>START</command> ou <command>COMMIT TRANSACTION</command>.
+ (Ceci change un peu avec &postgres; 8.0 puisque les transactions imbriquées,
+appelée également <quote>points de sauvegarde</quote> (<quote>
+ savepoints</quote>), sont supportés.
+De plus, les ordres DML non déterministes (par exemple mettre à jour un
+champ avec la valeur <function>CURRENT_TIMESTAMP</function>) doivent
+être évitées car les changements effectués par ce script ne sont pas
+explicitement répliqués.</para>
+
+ <variablelist>
+ <varlistentry><term><literal>SET ID = ival</literal></term>
+
+ <listitem><para>Le numéro unique de l'ensemble affecté par le script</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>FILENAME = '/chemin/vers/le/fichier'</literal></term>
+
+ <listitem><para>Le nom du fichier contenant le script SQL à exécuter.
+Il peut s'agir d'un chemin relatif à l'emplacement de l'instance <application>slonik</application>
+que vous avez lancé ou, de préférence, un chemin absolu sur le système où
+ <application>slonik</application> est lancé.</para>
+
+ <para>Le <emphasis>contenu</emphasis> de ce fichier est propagé dans un
+événement, donc il n'est pas nécessaire que le fichier soit accessible depuis
+les autres nœuds.
+ </para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>EVENT NODE = ival</literal></term>
+ <listitem><para>(Optionnel) L'identifiant de l'origine courante de l'ensemble. La valeur par défaut est 1.</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>EXECUTE ONLY ON = ival</literal></term>
+ <listitem><para>(Optionnel) L'identifiant du seul nœud qui
+doit exécuter le script. Cette option implique que le script sera propagé, par <xref linkend="slonik"/>,
+ <emphasis>seulement</emphasis> sur le seul nœud spécifié.
+Par défaut, on exécute le script sur tous les nœuds abonnés à l'ensemble de réplication.
+ </para></listitem>
+
+ </varlistentry>
+ </variablelist>
+
+ <para>Voir également les avertissements dans la section &rddlchanges;.</para>
+
+ <para>Notons qu'il s'agit d'une opération &rlocking;, ce qui signifie qu'elle peut être
+bloquée par l'activité d'une autre base.</para>
+
+ <para>Au démarrage de cet événement, toutes les tables répliquées sont
+déverrouillées par la fonction <function>alterTableRestore(tab_id)</function>.
+Une fois le script SQL exécuté, elles sont remises en <quote>mode réplication
+</quote> avec <function>alterTableForReplication(tab_id)</function>.
+Cela implique que toutes les tables sont verrouillées par ce processus
+&slon; pendant la durée du script SQL.</para>
+
+ <para>Si les colonnes d'une table sont modifiées, il est très
+important que les triggers soient régénérés, sinon ils peuvent
+être inadaptés à la nouvelle forme du schéma.
+ </para>
+
+ <para>Notez que si vous devez faire référence au nom du cluster,
+vous pouvez utiliser l'alias <command>@CLUSTERNAME@</command> ;
+si vous devez faire référence au schéma &slony1;,
+vous pouvez utiliser l'alias <command>@NAMESPACE@</command> ;
+les deux seront remplacés par la valeur appropriée. </para>
+
+ <para>Cette commande utilise &funddlscript;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+EXECUTE SCRIPT (
+ SET ID = 1,
+ FILENAME = '/tmp/changes_2004-05-01.sql',
+ EVENT NODE = 1
+);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Un verrou exclusif est posé
+sur chaque table répliquée sur le nœud origine, afin de retirer les triggers
+de réplication. Une fois le script DDL achevé, ces verrous sont enlevés.
+ </para>
+
+ <para>Une fois le script DDL exécuté sur le nœud origine, il est lancé sur les nœuds
+abonnés. Des verrous similaires sont posés sur tous les nœuds pour altérer
+les triggers des tables répliquées.
+ </para>
+
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+
+ <para>Avant la version 1.2, l'ensemble du script DDL était soumis
+dans une requête <function>PQexec()</function>, ce qui impliquait que
+le script <emphasis>tout entier</emphasis> était traité en se basant sur
+l'état de la base avant l'invocation du script. Cela signifie que
+des ordres placés à la fin d'un script ne pouvaient pas dépendre d'un ordre
+situé au début de ce même script. Ainsi, il n'était pas possible
+d'ajouter une colonne dans une table, puis une contrainte sur cette
+colonne au sein du même script.
+ </para>
+
+ <para>Dans &slony1; version 1.2, le script DDL est découpé ordre par ordre,
+et chaque ordre est soumis séparément. Cela implique que les ordres de la fin
+du script peuvent se référer aux objets ou aux attributs créés et modifiés au début
+du script.
+De plus, dans la version 1.2, le résultat de sortie de <command>slonik</command>
+contient la liste des ordre au fur et à mesure de leur traitement sur le nœud
+d'origine de l'ensemble de réplication. De même, les ordres traités sont listés
+dans les logs de slon sur les autres nœuds.
+ </para>
+
+ <para>Dans &slony1; version 1.0, cette commande verrouille uniquement les tables
+de l'ensemble spécifié. À partir de la version 1.1, <emphasis>toutes
+les tables répliquées</emphasis> sont verrouillées (<emphasis>c'est-à-dire</emphasis>
+que les triggers sont retirés au départ et restaurés à la fin).
+Ceci couvre les risques lorsqu'on lance une requête de changements DDL
+sur des tables appartenant à plusieurs ensemble de réplication.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtupdatefunctions"><refmeta><refentrytitle>UPDATE FUNCTIONS</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>UPDATE FUNCTIONS</refname>
+
+ <refpurpose>Recharge les procédures stockées</refpurpose></refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>UPDATE FUNCTIONS (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Cette commande recharge les procédures stockées pour un nœud.</para>
+
+ <para>Elle restaure toutes les procédures stockées et les définitions de fonctions dans
+le schéma &slony1; pour un nœud donné. Cette commande fait habituellement partie des
+procédure de mise à jour logicielles.
+ </para>
+
+ <variablelist>
+ <varlistentry><term><literal>ID = ival</literal></term>
+
+ <listitem><para>Le nœud à rafraîchir.</para></listitem>
+
+ </varlistentry>
+ </variablelist>
+
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+UPDATE FUNCTIONS (
+ ID = 3 # Update functions on node 3
+);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+ <refsect1> <title>Bizarreries</title>
+
+ <para>Toute incohérence entre <xref linkend="slonik"/> et la bibliothèque C
+ <quote>résidant</quote> dans l'installation de &postgres; empêchera le
+bon fonctionnement de l'ensemble et provoquera probablement une panne.
+Vous pouvez <emphasis>penser</emphasis> que vous mettez à jour avec la version
+1.1.5, mais si vous êtes en train d'utiliser la version 1.1.2, ou si vous
+n'avez pas redémarré la base avec une version qui a les bibliothèques 1.1.5,
+et que vous référencez des procédures stockées en C de la version 1.1.1,
+la tentative de mise à jour va échouer car les fonctionss C
+sont régulièrement modifiées entre les versions majeures.
+ </para>
+
+ <para>Avant &slony1; 1.2, le message d'erreur affiché n'était pas
+très informatif. Ce qu'on trouvait dans les traces de &postgres; était une
+erreur signalant l'impossibilité de charger des procédures stockées implémentées
+en C. À partir de la version 1.2, une des premières actions effectuées est
+le chargement d'une procédures stockées pour vérifier les numéros de versions ;
+Un message bien plus clair est affiché si vous utilisez des versions non
+cohérentes.
+ </para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtwaitevent"><refmeta><refentrytitle>WAIT FOR EVENT</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>WAIT FOR EVENT</refname>
+
+ <refpurpose>Demander à un script Slonik d'attendre que l'événement précédent s'achève</refpurpose></refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>WAIT FOR EVENT (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Cette commande attend une confirmation d'événement.</para>
+
+ <para><application>Slonik</application> se souvient du dernier événement
+généré sur chaque nœud pendant l'exécution d'un script (les événements produits
+lors des appels précédents ne sont pas vérifiés). Dans certaines situations,
+il est nécessaire que des événements générés sur un nœud (tel que
+ <command>CREATE SET</command>) soient traités sur un autre nœud avant de
+lancer d'autres commandes (par exemple <xref linkend="stmtsubscribeset"/>).
+<command>WAIT FOR EVENT</command> peut être utilisé pour demander à un
+script <application>slonik</application> d'attendre jusqu'à ce que le nœud abonné
+soit prêt pour l'action suivante.
+ </para>
+
+ <para><command>WAIT FOR EVENT</command> doit être appelée en dehors d'un
+bloc <command>try</command> car les nouveaux messages de confirmation ne sont
+pas visibles à l'intérieur d'une transaction.
+
+ <variablelist>
+ <varlistentry><term><literal>ORIGIN = ival | ALL</literal></term>
+ <listitem><para>L'origine de l'événement qu'il faut attendre.</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>CONFIRMED = ival | ALL</literal></term>
+
+ <listitem><para>L'identifiant du nœud récepteur qui doit confirmer le(s)
+événement(s).
+</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>WAIT ON = ival</literal></term>
+ <listitem><para>L'identifiant du nœud où la table &slconfirm; est vérifiée.
+La valeur par défaut est 1.</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>TIMEOUT = ival</literal></term>
+
+ <listitem><para>Le nombre de secondes d'attente. La valeur par défaut est 600
+ (10 minutes). <command>TIMEOUT = 0</command> implique que le script attend
+indéfiniment.</para></listitem>
+
+ </varlistentry>
+ </variablelist></para>
+
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+WAIT FOR EVENT (
+ ORIGIN = ALL,
+ CONFIRMED = ALL,
+ WAIT ON = 1
+);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ </refsect1>
+
+ <refsect1> <title>Bizarreries</title>
+<para>Tous les événements ne retournent pas forcément des résultats intéressants.
+Par exemple, beaucoup de gens ont rencontré énormément de problèmes avec
+<xref linkend="stmtsubscribeset"/> lorsqu'ils abonnaient un nouvel ensemble.
+Soyez conscient que la requête <xref linkend="stmtsubscribeset"/> va retourner
+la confirmation d'événement presque immédiatement, même s'il reste plusieurs heures
+de travail avant que l'abonnement ne soit achevé. Le problème avec
+ avec <xref linkend="stmtsubscribeset"/> est qu'il est traité par
+<emphasis>deux</emphasis> événements, un sur le nœud origine et un autre
+ qui met en place l'abonnement sur l'abonné.
+ </para>
+
+ <para>Afin de surveiller plus étroitement à l'intérieur du script <xref
+ linkend="slonik"/> que l'instruction <xref linkend="stmtsubscribeset"/>
+est complète, vous pouvez soumettre un événement <xref linkend="stmtsync"/>
+après l'abonnement et lancer une requête WAIT sur ce
+ <command>SYNC</command>, de la manière suivante : </para>
+ <programlisting>
+ # Supposons que l'ensemble 1 a deux abonnés direct 2 et 3
+ SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 2);
+ SYNC (ID=1);
+ WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 2, WAIT FOR=1);
+ SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 3);
+ SYNC (ID=1);
+ WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 3, WAIT FOR=1);
+ MERGE SET ( ID = 1, ADD ID = 999, ORIGIN = 1 );
+ </programlisting>
+ </refsect1>
+
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id="stmtrepairconfig"><refmeta><refentrytitle>REPAIR CONFIG</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>REPAIR CONFIG</refname>
+
+ <refpurpose>Remet à zéro les tables de correspondance entre les noms et les OID pour un
+ensemble de réplication, utile lorsqu'on restaure un nœud après un
+<application>pg_dump</application>.</refpurpose></refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>REPAIR CONFIG (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Remet à zéro la correspondance entre noms et OID.</para>
+
+ <variablelist>
+ <varlistentry><term><literal>SET ID = ival</literal></term>
+ <listitem><para>Le numéro de l'ensemble à nettoyer.</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>EVENT NODE = ival</literal></term>
+
+ <listitem><para>L'identifiant du nœud ou la commande doit être soumise.</para></listitem>
+
+ </varlistentry>
+ <varlistentry><term><literal>EXECUTE ONLY ON = ival</literal></term>
+
+ <listitem><para>L'identifiant du seul nœud où la correspondance est mise à jour.
+ Si cette valeur n'est pas précisée, par défaut on exécute la commande sur tous les
+ nœuds abonnés à l'ensemble.</para></listitem>
+
+ </varlistentry>
+ </variablelist>
+
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+REPAIR CONFIG (
+ SET ID = 1,
+ EVENT NODE = 2
+);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.1.</para>
+ </refsect1>
+ </refentry>
+<!-- **************************************** -->
+
+ <refentry id="stmtsync"><refmeta><refentrytitle>SYNC</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>SYNC</refname>
+
+ <refpurpose>Cette commande produit un événement SYNC ordinaire.</refpurpose></refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>SYNC (options);</command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+
+ <para>Cette commande génère un événement SYNC sur un nœud donné.</para>
+
+ <variablelist>
+ <varlistentry><term><literal>ID = ival</literal></term>
+ <listitem><para>Le nœud sur lequel on génère l'événement SYNC.</para></listitem>
+
+ </varlistentry>
+ </variablelist>
+
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ SUBSCRIBE SET (ID = 10, PROVIDER = 1, RECEIVER = 2);
+ WAIT FOR EVENT (ORIGIN = 2, CONFIRMED = 1);
+ SYNC (ID = 1);
+ WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 2);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Utilisation de verrous</title>
+
+ <para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.1.6 / 1.2.1.</para>
+ </refsect1>
+ </refentry>
+
+<!-- **************************************** -->
+
+ <refentry id ="stmtsleep"><refmeta><refentrytitle>SLEEP</refentrytitle>
+ <manvolnum>7</manvolnum></refmeta>
+
+ <refnamediv><refname>SLEEP</refname>
+
+ <refpurpose>S'endormir avec la fonction système <function>sleep()</function></refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>sleep </command>
+ <arg><replaceable class="parameter"> secondes</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>
+ Cette commande endort les opérations pendant un certain nombre de secondes.
+ </para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ sleep (seconds = 5);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.1.6 / 1.2.1.</para>
+ </refsect1>
+ </refentry>
+
+
+ </reference>
Deleted: traduc/tags/slony_1_2_12/slony.xml
===================================================================
--- traduc/trunk/slony/slony.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/slony.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,156 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
-"./dtd/4.3/docbookx.dtd" [
- <!ENTITY % version SYSTEM "version.xml">
- %version;
- <!ENTITY % filelist SYSTEM "filelist.xml">
- %filelist;
- <!ENTITY reference SYSTEM "reference.xml">
- <!ENTITY slony1 "<productname>Slony-I</productname>">
- <!ENTITY postgres "<productname>PostgreSQL</productname>">
- <!ENTITY nagios "<productname>Nagios</productname>">
- <!ENTITY windows "<trademark>Windows</trademark>">
- <!ENTITY logshiplink "<link linkend='logshipping'>log shipping</link>">
- <!ENTITY rlocking "<link linkend='locking'> locking </link>">
- <!ENTITY rddlchanges "<xref linkend='ddlchanges'/>">
- <!ENTITY fundroplisten "<xref linkend='function.droplisten-integer-integer-integer'/>">
- <!ENTITY fundropset "<xref linkend='function.dropset-integer'/>">
- <!ENTITY funmergeset "<xref linkend='function.mergeset-integer-integer'/>">
- <!ENTITY funsetdroptable "<xref linkend='function.setdroptable-integer'/>">
- <!ENTITY funstorelisten "<xref linkend='function.storelisten-integer-integer-integer'/>">
- <!ENTITY funstorepath "<xref linkend='function.storepath-integer-integer-text-integer'/>">
- <!ENTITY funstoreset "<xref linkend='function.storeset-integer-text'/>">
- <!ENTITY funtableaddkey "<xref linkend='function.tableaddkey-text'/>">
- <!ENTITY funsetaddtable "<xref linkend='function.setaddtable-integer-integer-text-name-text'/>">
- <!ENTITY funsetaddsequence "<xref linkend='function.setaddsequence-integer-integer-text-text'/>">
- <!ENTITY funsetdropsequence "<xref linkend='function.setdropsequence-integer'/>">
- <!ENTITY funsetmovetable "<xref linkend='function.setmovetable-integer-integer'/>">
- <!ENTITY fundroptrigger "<xref linkend='function.droptrigger-integer-name'/>">
- <!ENTITY funddlscript "<xref linkend='function.ddlscript-complete-integer-text-integer'/>">
- <!ENTITY fundropnode "<xref linkend='function.dropnode-integer'/>">
- <!ENTITY funenablenode "<xref linkend='function.enablenode-integer'/>">
- <!ENTITY funfailednode "<xref linkend='function.failednode-integer-integer'/>">
- <!ENTITY funinitializelocalnode "<xref linkend='function.initializelocalnode-integer-text'/>">
- <!ENTITY funlockset "<xref linkend='function.lockset-integer'/>">
- <!ENTITY funmoveset "<xref linkend='function.moveset-integer-integer'/>">
- <!ENTITY funsetmovesequence "<xref linkend='function.setmovesequence-integer-integer'/>">
- <!ENTITY funstoretrigger "<xref linkend='function.storetrigger-integer-name'/>">
- <!ENTITY funsubscribeset "<xref linkend='function.subscribeset-integer-integer-integer-boolean'/>">
- <!ENTITY fununinstallnode "<xref linkend='function.uninstallnode'/>">
- <!ENTITY fununlockset "<xref linkend='function.unlockset-integer'/>">
- <!ENTITY fununsubscribeset "<xref linkend='function.unsubscribeset-integer-integer'/>">
- <!ENTITY bestpracticelink "<link linkend='bestpractices'>Best Practice</link>">
- <!ENTITY rmissingoids "<link linkend='missingoids'>error messages indicating missing OIDs</link>">
- <!ENTITY slnode "<xref linkend='table.sl-node'/>">
- <!ENTITY sllog1 "<xref linkend='table.sl-log-1'/>">
- <!ENTITY sllog2 "<xref linkend='table.sl-log-2'/>">
- <!ENTITY slconfirm "<xref linkend='table.sl-confirm'/>">
- <!ENTITY rplainpaths "<xref linkend='plainpaths'/>">
- <!ENTITY rlistenpaths "<xref linkend='listenpaths'/>">
- <!ENTITY pglistener "<envar>pg_listener</envar>">
- <!ENTITY lslon "<xref linkend='slon'/>">
- <!ENTITY lslonik "<xref linkend='slonik'/>">
- <!ENTITY lfrenchtranslation "<xref linkend='frenchtranslation'/>">
-]>
-
-<book id="slony" lang="fr">
- <title>Documentation &slony1; &version;</title>
- <bookinfo>
- <corpauthor>The PostgreSQL Global Development Group</corpauthor>
- <author>
- <firstname>Christopher</firstname>
- <surname>Browne</surname>
- </author>
- &legal;
- </bookinfo>
-
- <article id="slonyintro">
- <title>Introduction à &slony1;</title>
-
- &intro;
- &prerequisites;
- &installation;
- &concepts;
- &cluster;
- &defineset;
-
- </article>
-
- &reference;
-
- <article id="slonyadmin">
- <title>Administration Slony-I</title>
- <articleinfo>
- <corpauthor>The PostgreSQL Global Development Group</corpauthor>
- <author> <firstname>Christopher</firstname> <surname>Browne</surname> </author>
- </articleinfo>
-
- &bestpractices;
- &firstdb;
- &startslons;
- &subscribenodes;
- &monitoring;
- &maintenance;
- &reshape;
- &failover;
- &listenpaths;
- &plainpaths;
- &triggers;
- &locking;
- &raceconditions;
- &addthings;
- &dropthings;
- &logshipfile;
- &ddlchanges;
- &usingslonik;
- &adminscripts;
- &partitioning;
- &slonyupgrade;
- &versionupgrade;
- &testbed;
- &loganalysis;
- &help;
- &supportedplatforms;
- &releasechecklist;
-
- </article>
-
- <article id="faq">
- <title>FAQ Slony-I</title>
- <articleinfo>
- <corpauthor>The Slony Global Development Group</corpauthor>
- <author><firstname>Christopher </firstname><surname>Browne</surname></author>
- </articleinfo>
-
- <para>
- Ces questions ne sont pas toutes, au sens strict, des questions
- <quote>fréquemment posées</quote> ; certaines illustrent des
- <emphasis>problèmes identifiés qu'il semble bon de documenter</emphasis>.
- </para>
-
- &faq;
-
- </article>
-
- <part id="commandreference">
- <title>Le Cœur de &slony1;</title>
-
- &slon;
- &slonconf;
- &slonik;
- &slonikref;
-
- </part>
-
- &schemadoc;
- <!-- &bookindex; -->
-
- &frenchtranslation;
-
-</book>
Copied: traduc/tags/slony_1_2_12/slony.xml (from rev 1244, traduc/trunk/slony/slony.xml)
===================================================================
--- traduc/tags/slony_1_2_12/slony.xml (rev 0)
+++ traduc/tags/slony_1_2_12/slony.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,155 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+"./dtd/4.3/docbookx.dtd" [
+ <!ENTITY % version SYSTEM "version.xml">
+ %version;
+ <!ENTITY % filelist SYSTEM "filelist.xml">
+ %filelist;
+ <!ENTITY reference SYSTEM "reference.xml">
+ <!ENTITY slony1 "<productname>Slony-I</productname>">
+ <!ENTITY postgres "<productname>PostgreSQL</productname>">
+ <!ENTITY nagios "<productname>Nagios</productname>">
+ <!ENTITY windows "<trademark>Windows</trademark>">
+ <!ENTITY logshiplink "<link linkend='logshipping'>log shipping</link>">
+ <!ENTITY rlocking "<link linkend='locking'> locking </link>">
+ <!ENTITY rddlchanges "<xref linkend='ddlchanges'/>">
+ <!ENTITY fundroplisten "<xref linkend='function.droplisten-integer-integer-integer'/>">
+ <!ENTITY fundropset "<xref linkend='function.dropset-integer'/>">
+ <!ENTITY funmergeset "<xref linkend='function.mergeset-integer-integer'/>">
+ <!ENTITY funsetdroptable "<xref linkend='function.setdroptable-integer'/>">
+ <!ENTITY funstorelisten "<xref linkend='function.storelisten-integer-integer-integer'/>">
+ <!ENTITY funstorepath "<xref linkend='function.storepath-integer-integer-text-integer'/>">
+ <!ENTITY funstoreset "<xref linkend='function.storeset-integer-text'/>">
+ <!ENTITY funtableaddkey "<xref linkend='function.tableaddkey-text'/>">
+ <!ENTITY funsetaddtable "<xref linkend='function.setaddtable-integer-integer-text-name-text'/>">
+ <!ENTITY funsetaddsequence "<xref linkend='function.setaddsequence-integer-integer-text-text'/>">
+ <!ENTITY funsetdropsequence "<xref linkend='function.setdropsequence-integer'/>">
+ <!ENTITY funsetmovetable "<xref linkend='function.setmovetable-integer-integer'/>">
+ <!ENTITY fundroptrigger "<xref linkend='function.droptrigger-integer-name'/>">
+ <!ENTITY funddlscript "<xref linkend='function.ddlscript-complete-integer-text-integer'/>">
+ <!ENTITY fundropnode "<xref linkend='function.dropnode-integer'/>">
+ <!ENTITY funenablenode "<xref linkend='function.enablenode-integer'/>">
+ <!ENTITY funfailednode "<xref linkend='function.failednode-integer-integer'/>">
+ <!ENTITY funinitializelocalnode "<xref linkend='function.initializelocalnode-integer-text'/>">
+ <!ENTITY funlockset "<xref linkend='function.lockset-integer'/>">
+ <!ENTITY funmoveset "<xref linkend='function.moveset-integer-integer'/>">
+ <!ENTITY funsetmovesequence "<xref linkend='function.setmovesequence-integer-integer'/>">
+ <!ENTITY funstoretrigger "<xref linkend='function.storetrigger-integer-name'/>">
+ <!ENTITY funsubscribeset "<xref linkend='function.subscribeset-integer-integer-integer-boolean'/>">
+ <!ENTITY fununinstallnode "<xref linkend='function.uninstallnode'/>">
+ <!ENTITY fununlockset "<xref linkend='function.unlockset-integer'/>">
+ <!ENTITY fununsubscribeset "<xref linkend='function.unsubscribeset-integer-integer'/>">
+ <!ENTITY bestpracticelink "<link linkend='bestpractices'>Best Practice</link>">
+ <!ENTITY rmissingoids "<link linkend='missingoids'>error messages indicating missing OIDs</link>">
+ <!ENTITY slnode "<xref linkend='table.sl-node'/>">
+ <!ENTITY sllog1 "<xref linkend='table.sl-log-1'/>">
+ <!ENTITY sllog2 "<xref linkend='table.sl-log-2'/>">
+ <!ENTITY slconfirm "<xref linkend='table.sl-confirm'/>">
+ <!ENTITY rplainpaths "<xref linkend='plainpaths'/>">
+ <!ENTITY rlistenpaths "<xref linkend='listenpaths'/>">
+ <!ENTITY pglistener "<envar>pg_listener</envar>">
+ <!ENTITY lslon "<xref linkend='slon'/>">
+ <!ENTITY lslonik "<xref linkend='slonik'/>">
+ <!ENTITY lfrenchtranslation "<xref linkend='frenchtranslation'/>">
+]>
+
+<book id="slony" lang="fr">
+ <title>Documentation &slony1; &version;</title>
+ <bookinfo>
+ <corpauthor>The PostgreSQL Global Development Group</corpauthor>
+ <author>
+ <firstname>Christopher</firstname>
+ <surname>Browne</surname>
+ </author>
+ &legal;
+ </bookinfo>
+
+ <article id="slonyintro">
+ <title>Introduction à &slony1;</title>
+
+ &intro;
+ &prerequisites;
+ &installation;
+ &concepts;
+ &cluster;
+ &defineset;
+
+ </article>
+
+ &reference;
+
+ <article id="slonyadmin">
+ <title>Administration Slony-I</title>
+ <articleinfo>
+ <corpauthor>The PostgreSQL Global Development Group</corpauthor>
+ <author> <firstname>Christopher</firstname> <surname>Browne</surname> </author>
+ </articleinfo>
+
+ &bestpractices;
+ &firstdb;
+ &startslons;
+ &subscribenodes;
+ &monitoring;
+ &maintenance;
+ &reshape;
+ &failover;
+ &listenpaths;
+ &plainpaths;
+ &locking;
+ &addthings;
+ &dropthings;
+ &logshipfile;
+ &ddlchanges;
+ &usingslonik;
+ &adminscripts;
+ &partitioning;
+ &slonyupgrade;
+ &versionupgrade;
+ &testbed;
+ &loganalysis;
+ &help;
+
+ </article>
+
+ <article id="faq">
+ <title>FAQ Slony-I</title>
+ <articleinfo>
+ <corpauthor>The Slony Global Development Group</corpauthor>
+ <author><firstname>Christopher </firstname><surname>Browne</surname></author>
+ </articleinfo>
+
+ <para>
+ Ces questions ne sont pas toutes, au sens strict, des questions
+ <quote>fréquemment posées</quote> ; certaines illustrent des
+ <emphasis>problèmes identifiés qu'il semble bon de documenter</emphasis>.
+ </para>
+
+ &faq;
+
+ </article>
+
+ <part id="commandreference">
+ <title>Le Cœur de &slony1;</title>
+
+ &slon;
+ &slonconf;
+ &slonik;
+ &slonikref;
+
+ </part>
+
+
+ &supportedplatforms;
+ &releasechecklist;
+ &schemadoc;
+ <!-- &bookindex; -->
+
+ &frenchtranslation;
+
+</book>
Deleted: traduc/tags/slony_1_2_12/slonyupgrade.xml
===================================================================
--- traduc/trunk/slony/slonyupgrade.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/slonyupgrade.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,381 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="slonyupgrade">
-<title>Mise à jour de &slony1;</title>
-<indexterm><primary>remplacer &slony1; par une nouvelle version</primary></indexterm>
-
-<para>
- Lorsqu'on met à jour &slony1;, chaque nœud du cluster doit être mis à
- jour simultanément, en utilisant la commande <xref
- linkend="stmtupdatefunctions"/> de &lslonik;.
-</para>
-
-<para>
- Cela nécessite un arrêt temporaire de la réplication, mais cela n'implique
- pas obligatoirement une coupure de service au niveau des applications qui
- utilisent le cluster.
-</para>
-
-<para>
- La procédure correcte est la suivante :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Arrêtez les processus &lslon; sur chaque nœud
- (<emphasis>c'est-à-dire</emphasis> l'ancienne version de &lslon;).
- </para>
- </listitem>
-
- <listitem>
- <para>
- Installez la nouvelle version du logiciel &lslon; sur tous les
- nœuds.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Exécutez un script &lslonik; contenant la commande
- <command>update functions (id = [valeur]);</command> pour chaque
- nœud du cluster.
- </para>
-
- <note>
- <para>
- Souvenez-vous que le script de mise à jour, comme tous les scripts
- &slonik; doit contenir les fonctions adéquates pour fonctionner.
- </para>
- </note>
- </listitem>
-
- <listitem>
- <para>
- Démarrez tous les démons slons.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Toute cette opération est relativement sûre : s'il y a une incohérence
- entre les versions des composants, le &lslon; refusera de démarrer, ce qui
- constitue une protection contre les corruptions.
-</para>
-
-<para>
- Vous devez vous assurer que la bibliothèque C contenant les fonctions trigger
- SPI ont été copiées à la bonne place lors de la compilation de &postgres;. Il
- existe de multiples approches pour cela :
-</para>
-
-<para>
- La partie la plus compliquée consiste à s'assurer que la bibliothèque C
- contenant les fonctions SPI est copiée au bon endroit lors de la compilation
- de &postgres; ; la manière la plus simple et la plus sûre de faire cela
- consiste à avoir deux versions compilées de &postgres;, une pour chaque
- version de &slony1;, puis d'éteindre le serveur et de le relancer avec la
- <quote>nouvelle</quote> version compilée ; cette approche implique une
- courte coupure de service sur chaque nœud.
-</para>
-
-<para>
- Si cette approche est réputée plus simple et plus rapide, rien ne vous
- empêche de mettre en place avec précaution les composants &slony1; pour
- écraser l'ancienne version comme décrit dans l'étape d'installation. Ceci
- peut ne <emphasis>pas</emphasis> fonctionner sous Windows si Windows pose un
- verrou sur les fichiers qui sont utilisés.
-</para>
-
-<variablelist>
- <varlistentry>
- <term>Exécuter <command>make install</command> pour installer les nouveaux
- composants &slony1; au dessus des anciens.</term>
-
- <listitem>
- <para>
- Si vous compilez &slony1; sur le système sur où il sera déployé et
- que vous compilez à partir des sources, écraser l'ancienne version avec
- la nouvelle se fait simplement avec <command>make install</command>.
- Il n'est pas nécessaire de relancer la base de donnée, il faut juste
- arrêter les processus &slony1;, exécuter le script <command>UPDATE
- FUNCTIONS</command> et démarrer les nouveaux processus &lslon;.
- </para>
-
- <para>
- Malheureusement, cette approche nécessite un environnement de
- compilation sur le serveur où la mise à jour sera déployée. Ceci n'est
- pas forcément compatible avec la volonté d'utiliser des binaires
- communs à &postgres; et &slony1; sur l'ensemble des nœuds.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Compiler à nouveau &postgres; et &slony1;</term>
-
- <listitem>
- <para>
- Avec cette approche, l'ancienne version de &postgres; accompagnée des
- anciens composants &slony1; est conservée après la bascule vers une
- nouvelle version de &postgres; accompagnée des nouveaux composants
- &slony1;. Afin de basculer vers la nouvelle version de &slony1;, vous
- devez redémarrer le serveur <command>postmaster</command>, ce qui
- implique l'interruption des applications. afin que le serveur soit
- informé de l'emplacement des nouveaux composants.
- </para>
- </listitem>
- </varlistentry>
-</variablelist>
-
-<sect2>
-<title>Problème avec TABLE ADD KEY dans &slony1; 2.0</title>
-
-<para>
- Généralement, les mises à jour de versions &slony1; ne nécessitent pas de
- porter une attention particulière au réplicat existant, c'est-à-dire que vous
- pouvez simplement arrêter les &slon;s, mettre en place les binaires, lancer
- <xref linkend="stmtupdatefunctions"/> sur chaque nœud et redémarrer
- &lslon;. Les modifications de schéma étant uniquement sur le schéma du cluster,
- <xref linkend="stmtupdatefunctions"/> est capable de réaliser toutes les
- altérations. Avec la version 2, cela change s'il existe des tables qui
- utilisaient <xref linkend="stmttableaddkey"/>. La version 2 ne supporte pas
- la colonne <quote>extra</quote>, et <quote>réparer</quote> le schéma pour
- obtenir une clé primaire correcte n'est pas dans les attributions de <xref
- linkend="stmtupdatefunctions"/>.
-</para>
-
-<para>
- Lorsque qu'on met à jour depuis une version 1.0.x, 1.1.x ou 1.2.x vers une
- version 2, il est nécessaire de supprimer toute clé primaire gérée par
- &slony1;.
-</para>
-
-<para>
- On peut identifier les tables concernées avec la requête SQL suivante :
-
- <command>SELECT n.nspname, c.relname FROM pg_class c,
-pg_namespace n WHERE c.oid in (SELECT attrelid FROM pg_attribute WHERE
-attname LIKE '_Slony-I_%rowID' and not attisdropped) and reltype &lt&gt 0
-and n.oid = c.relnamespace order by n.nspname, c.relname;</command>
-
-</para>
-
-<para>
- L'approche la plus simple pour rectifier l'état de ces tables est la
- suivante :
-</para>
-
-<itemizedlist>
-
- <listitem>
- <para>
- Retirer la table de la réplication avec la commande &lslonik;
- <xref linkend="stmtsetdroptable"/>
- </para>
-
- <para>
- Ceci ne supprime <emphasis>pas</emphasis> les colonnes créées par
- &slony1;.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Sur chaque nœud, exécutez un script SQL pour modifier la table et
- supprimez les colonnes additionnelles.
- </para>
-
- <para>
- <command>ALTER TABLE nom_table DROP COLUMN "_Slony-I_cluster-rowID";</command>
- </para>
-
- <para>
- Ceci doit être exécuté sur chaque nœud. Selon votre préférence,
- vous pouvez utiliser <xref linkend="stmtddlscript"/> pour cela.
- </para>
-
- <para>
- Si la table est une table massivement mise à jour, sachez que cette
- modification posera un verrou exclusif sur la table. Elle ne détiendra
- pas ce verrou très longtemps ; supprimer une colonne est une
- opération assez rapide car cela se contente de marquer la colonne comme
- supprimée. Cela ne nécessite <emphasis>pas</emphasis> de réécrire toute
- la table. Les lignes qui ont une valeur dans cette colonne continueront à
- avoir cette valeur. Pour les nouvelles lignes, la valeur sera NULL, et
- les requêtes ignoreront cette colonne. L'espace occupé par ces colonnes
- sera récupéré lorsque les lignes seront mises à jour.
- </para>
-
- <para>
- Notez qu'à cette étape de la procédure, cette table n'est pas répliquée.
- Si une erreur a lieu, la réplication à cet instant n'apporte aucune
- protection sur cette table. C'est dommage mais inévitable.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Assurez-vous que la table possède un candidat éligible pour une clé
- primaire, c'est-à-dire un ensemble de colonnes NOT NULL et UNIQUE.
- </para>
-
- <para>
- Les différents cas possibles font que les développeurs n'ont pas fait
- d'efforts pour automatiser cette procédure.
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- Si la table est petite, il peut être parfaitement raisonnable
- d'ajouter une nouvelle colonne (notez que cela doit être fait sur
- <emphasis>chaque nœud</emphasis> !), lui assigner une
- une nouvelle séquence et la déclarer comme clé primaire.
- </para>
-
- <para>
- S'il n'y a que quelques lignes, cela ne prend qu'une fraction de
- seconde et avec de la chance, cela n'aura pas d'impact sur
- l'application.
- </para>
-
- <para>
- Même si la table est relativement large, alors qu'elle n'est pas
- accédée fréquemment par l'application, alors le verrouillage de la
- table provoqué par <command>ALTER TABLE</command> n'entraînera pas
- d'inconvénients.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si la table est large, qu'elle est vitale et fortement utilisée par
- l'application, alors il peut être nécessaire de prévoir une coupure
- de service de l'application afin d'accomplir les modifications, ce
- qui vous laissera un peu vulnérable tant que la procédure ne sera pas
- complétée.
- </para>
-
- <para>
- Si une coupure de service est problématique, alors la mise à jour
- vers &slony1; version 2 devra être planifiée avec soin...
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- Créez un nouvel ensemble de réplication (<xref linkend="stmtcreateset"/>
- et ajoutez à nouveau la table dans cet ensemble (<xref
- linkend="stmtsetaddtable"/>).
- </para>
-
- <para>
- S'il existe plusieurs tables, elles peuvent être gérées via un ensemble
- de réplication unique.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Abonnez l'ensemble de réplication (<xref linkend="stmtsubscribeset"/>)
- pour tous les nœuds désirés.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Une fois que l'abonnement est complété, fusionnez les ensembles de
- réplications si nécessaire (<xref linkend="stmtmergeset"/>).
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Cette approche devrait fonctionner pour les tables qui sont relativement
- petites ou rarement utilisées. D'autre part, si la table est large et
- massivement utilisée, une autre approche pourrait être nécessaire,
- c'est-à-dire créer votre propre séquence, et <quote>promouvoir</quote>
- l'ancienne colonne générée par &slony1; dans une colonne <quote>réelle</quote>
- au sein du schéma de votre base de données. Les grandes lignes de cette
- procédure sont les suivantes :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Ajouter une séquence qui assigne des valeurs à la colonne.
- </para>
-
- <para>
- Les étapes d'installation incluent les commandes SQL <command>CREATE
- SEQUENCE</command>, <command>SELECT SETVAL()</command> (pour définir
- une valeur de séquence assez haute pour refléter les valeurs utilisées
- dans la table), le <xref linkend="stmtcreateset"/> de Slonik (pour créer
- un ensemble de réplication dans lequel on placera la séquence), le
- <xref linkend="stmtsetaddsequence"/> de Slonik (pour placer la séquence
- dans l'ensemble de réplication), le <xref linkend="stmtsubscribeset"/>
- de Slonik (pour définir les abonnements de ce nouvel ensemble de
- réplication).
- </para>
- </listitem>
-
- <listitem>
- <para>
- Attachez la séquence à la colonne dans la table.
- </para>
-
- <para>
- Ceci implique les commandes <command>ALTER TABLE ALTER COLUMN</command>,
- qui doivent être exécutées via la commande Slonik <xref
- linkend="stmtddlscript"/>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Renommez la colonne <envar>_Slony-I_ at CLUSTERNAME@_rowID</envar> afin que
- &slony1; ne considère pas qu'elle est sous son contrôle.
- </para>
-
- <para>
- Ceci implique les commandes <command>ALTER TABLE ALTER COLUMN</command>,
- qui doivent être exécutées via la commande Slonik <xref
- linkend="stmtddlscript"/>.
- </para>
-
- <para>
- Notez que ces deux modifications peuvent être accomplies au sein d'une
- requête <xref linkend="stmtddlscript"/> unique.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-<sect2>
-<title>Nouvelle gestion des triggers dans &slony1; Version 2</title>
-
-<para>
- Un des changements majeurs de &slony1; est que l'activation et la
- désactivation des triggers et règles (« rules ») se fait
- maintenant entièrement en SQL, supporté par &postgres; 8.3+, plutôt
- que via des modifications directes dans le catalogue système.
-</para>
-
-<para>
- Cela implique que les utilisateurs de &slony1; doivent étudier la syntaxe
- &postgres; pour <command>ALTER TABLE</command> car c'est ainsi qu'ils
- accompliront ce qu'ils accomplissait précédemment via les commandes <xref
- linkend="stmtstoretrigger"/> et <xref linkend="stmtdroptrigger"/>.
-</para>
-
-</sect2>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/slonyupgrade.xml (from rev 1244, traduc/trunk/slony/slonyupgrade.xml)
===================================================================
--- traduc/tags/slony_1_2_12/slonyupgrade.xml (rev 0)
+++ traduc/tags/slony_1_2_12/slonyupgrade.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,135 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="slonyupgrade">
+<title>Mise à jour de &slony1;</title>
+<indexterm><primary>remplacer &slony1; par une nouvelle version</primary></indexterm>
+
+<para>
+ Lorsqu'on met à jour &slony1;, chaque nœud du cluster doit être mis à
+ jour simultanément, en utilisant la commande <xref
+ linkend="stmtupdatefunctions"/> de &lslonik;.
+</para>
+
+<para>
+ Cela nécessite un arrêt temporaire de la réplication, mais cela n'implique
+ pas obligatoirement une coupure de service au niveau des applications qui
+ utilisent le cluster.
+</para>
+
+<para>
+ La procédure correcte est la suivante :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Arrêtez les processus &lslon; sur chaque nœud
+ (<emphasis>c'est-à-dire</emphasis> l'ancienne version de &lslon;).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Installez la nouvelle version du logiciel &lslon; sur tous les
+ nœuds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Exécutez un script &lslonik; contenant la commande
+ <command>update functions (id = [valeur]);</command> pour chaque
+ nœud du cluster.
+ </para>
+
+ <note>
+ <para>
+ Souvenez-vous que le script de mise à jour, comme tous les scripts
+ &slonik; doit contenir les fonctions adéquates pour fonctionner.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ Démarrez tous les démons slons.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Toute cette opération est relativement sûre : s'il y a une incohérence
+ entre les versions des composants, le &lslon; refusera de démarrer, ce qui
+ constitue une protection contre les corruptions.
+</para>
+
+<para>
+ Vous devez vous assurer que la bibliothèque C contenant les fonctions trigger
+ SPI ont été copiées à la bonne place lors de la compilation de &postgres;. Il
+ existe de multiples approches pour cela :
+</para>
+
+<para>
+ La partie la plus compliquée consiste à s'assurer que la bibliothèque C
+ contenant les fonctions SPI est copiée au bon endroit lors de la compilation
+ de &postgres; ; la manière la plus simple et la plus sûre de faire cela
+ consiste à avoir deux versions compilées de &postgres;, une pour chaque
+ version de &slony1;, puis d'éteindre le serveur et de le relancer avec la
+ <quote>nouvelle</quote> version compilée ; cette approche implique une
+ courte coupure de service sur chaque nœud.
+</para>
+
+<para>
+ Si cette approche est réputée plus simple et plus rapide, rien ne vous
+ empêche de mettre en place avec précaution les composants &slony1; pour
+ écraser l'ancienne version comme décrit dans l'étape d'installation. Ceci
+ peut ne <emphasis>pas</emphasis> fonctionner sous Windows si Windows pose un
+ verrou sur les fichiers qui sont utilisés.
+</para>
+
+<variablelist>
+ <varlistentry>
+ <term>Exécuter <command>make install</command> pour installer les nouveaux
+ composants &slony1; au dessus des anciens.</term>
+
+ <listitem>
+ <para>
+ Si vous compilez &slony1; sur le système sur où il sera déployé et
+ que vous compilez à partir des sources, écraser l'ancienne version avec
+ la nouvelle se fait simplement avec <command>make install</command>.
+ Il n'est pas nécessaire de relancer la base de donnée, il faut juste
+ arrêter les processus &slony1;, exécuter le script <command>UPDATE
+ FUNCTIONS</command> et démarrer les nouveaux processus &lslon;.
+ </para>
+
+ <para>
+ Malheureusement, cette approche nécessite un environnement de
+ compilation sur le serveur où la mise à jour sera déployée. Ceci n'est
+ pas forcément compatible avec la volonté d'utiliser des binaires
+ communs à &postgres; et &slony1; sur l'ensemble des nœuds.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Compiler à nouveau &postgres; et &slony1;</term>
+
+ <listitem>
+ <para>
+ Avec cette approche, l'ancienne version de &postgres; accompagnée des
+ anciens composants &slony1; est conservée après la bascule vers une
+ nouvelle version de &postgres; accompagnée des nouveaux composants
+ &slony1;. Afin de basculer vers la nouvelle version de &slony1;, vous
+ devez redémarrer le serveur <command>postmaster</command>, ce qui
+ implique l'interruption des applications. afin que le serveur soit
+ informé de l'emplacement des nouveaux composants.
+ </para>
+ </listitem>
+ </varlistentry>
+</variablelist>
+
+</sect1>
Deleted: traduc/tags/slony_1_2_12/subscribenodes.xml
===================================================================
--- traduc/trunk/slony/subscribenodes.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/subscribenodes.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,159 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- DerniÚre modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="subscribenodes">
-<title>Enregistrement des serveurs</title>
-<indexterm><primary>Enregistrement des serveurs</primary></indexterm>
-
-<para>
- Avant d'enregistrer un serveur à un ensemble, assurez-vous d'avoir un
- processus <xref linkend="slon"/> pour chacune des deux parties à savoir le
- fournisseur et pour le nouveau nœud de souscription. Si les démons slon
- respectifs ne sont pas en cours d'exécution, alors il ne se passera rien et
- vous vous éverturez à comprendre pourquoi cela ne fonctionne pas.
-</para>
-
-<para>
- Ajouter un serveur à un ensemble de serveurs est fait en exécutant la commande
- <xref linkend="stmtsubscribeset"/> de <xref linkend="slonik"/> . Il peut
- sembler tentant d'essayer de souscrire plusieurs nœuds à un ensemble
- dans un bloc d'essai simple comme celui-ci :
-
-<programlisting>
-try {
- echo 'Subscribing sets';
- subscrifbe set (id = 1, provider=1, receiver=2, forward=yes);
- subscribe set (id = 1, provider=1, receiver=3, forward=yes);
- subscribe set (id = 1, provider=1, receiver=4, forward=yes);
-} on error {
- echo 'Enregistrement du jeu des serveurs : impossible!';
- exit -1;
-}
-</programlisting>
-</para>
-
-<para>
- Mais vous êtes juste en train de vous demander quel est le souci en
- enregistrant les ensembles de serveurs de cette façon. La méthode
- appropriée exige de procéder à l'enregistrement des serveurs, à raison
- d'un seul à la fois, tout en examinant le journal de l'instance de la
- base de donnée, avant de vous occuper du prochain enregistrement. Il est
- également intéressant de noter que le <quote>succès</quote> dans l'essai
- <xref linkend="slonik"/> ci-dessus, n'implique pas que les nœuds 2,
- 3, et 4 soient tous enregistrés avec succès. Il indique simplement que les
- commandes de slonik ont été reçues avec succès le démon
- <application>slon</application> fonctionnant sur le nœud d'origine.
-</para>
-
-<para>
- Un cas typique de problème pouvant surgir est qu'un abonné en cascade,
- recherche un fournisseur qui n'est pas encore prêt. Dans ce cas d'échec, le
- nœud souscripteur ne deviendra <emphasis>jamais</emphasis> l'abonné.
- Il sera <quote>bloquée</quote> en attente d'un évènement déjà survenu.
- Les autres nœuds seront persuadés que, ce nœud bloqué s'est
- enregistré correctement (parce qu'aucune erreur ne leur est parvenu) ;
- la demande pour désabonner le nœud sera <quote>bloqué</quote> car le
- nœud en question est coincé en attente d'enregistrement.
-</para>
-
-<para>
- Lorsque vous enregistrez un nœud à un ensemble de nœuds, vous
- devez voir quelque chose de ce genre dans les traces du démon
- <application>slon</application> pour le nœud fournisseur :
-
-<screen>
-DEBUG2 remoteWorkerThread_3: Received event 3,1059 SUBSCRIBE_SET
-</screen>
-</para>
-
-<para>
- Vous devriez également commencer à voir des messages de ce genre dans les
- traces du démon <application>slon</application> pour le nœud de
- souscription :
-
-<screen>
-DEBUG2 remoteWorkerThread_1: copy table public.my_table
-</screen>
-</para>
-
-<para>
- La copie de grandes tables entre le nœud de fournisseur et le nouvel
- abonné peut prendre un certain temps. Si vous vérifiez la table
- pg_stat_activity sur le nœud du fournisseur, vous devriez voir une
- requête qui copie la table vers stdout.
-</para>
-
-<para>
- La table <envar>sl_subscribe</envar> pour le fournisseur comme pour le
- nouveau souscripteur, doit contenir un enregistrement pour le nouveau
- abonnement :
-
-<screen>
- sub_set | sub_provider | sub_receiver | sub_forward | sub_active
----------+--------------+--------------+-------------+------------
- 1 | 1 | 2 | t | t
-</screen>
-</para>
-
-<para>
- Un ultime test est d'insérer un enregistrement dans une des tables répliquées
- depuis le nœud d'origine, et de vérifier que cet enregistrement est bien
- répliqué chez le souscripteur.
-</para>
-
-<warning>
- <para>
- Si vous créez et souscrivez à un ensemble de nœud qui ne contient
- aucune table, cela peut mener à une situation qui empêchera la réplication
- de se faire.
- </para>
-
- <para>
- Notez que ce bug est corrigé depuis la version 1.1.5.
- </para>
-
- <para>
- Si un abonné particulier est seulement alimenté par une séquence d'ordre
- d'un de ces fournisseurs, la requête qui collecte l'évènement
- <command>SYNC</command> ne sera pas correctement créée, et vous pouvez
- voir une erreur similaire celle-ci :
- </para>
-
- <screen>2007-04-13 07:11:28 PDT ERROR remoteWorkerThread_11: "declare LOG
-cursor for select log_origin, log_xid, log_tableid, log_actionseq,
-log_cmdtype, log_cmddata from "_T1".sl_log_1 where log_origin = 11 and
-( order by log_actionseq; " PGRES_FATAL_ERROR ERROR: syntax error at
-or near "order" at character 162</screen>
-
- <para>
- La fonction <xref
- linkend="function.subscribeset-integer-integer-integer-boolean"/> va
- générer un avertissement si un ensemble de réplication donné ne contient
- aucune table à répliquer, comme l'exemple suivant le montre :
- </para>
-
- <screen>cbbrowne at dba2:/tmp> cat create_empty_set.slonik
-cluster name = T1;
-node 11 admin conninfo = 'dbname=slony_test1';
-node 22 admin conninfo = 'dbname=slony_test2';
-
-create set (id = 255, origin = 11, comment='blank empty set');
-subscribe set (id=255, provider = 11, receiver = 22, forward = false);</screen>
-
- <para>
- Ceci mène au message d'avertissement suivant :
- </para>
-
- <screen>bbrowne at dba2:/tmp> slonik create_empty_set.slonik
-create_empty_set.slonik:6: NOTICE: subscribeSet:: set 255 has no tables
-- risk of problems - see bug 1226
-create_empty_set.slonik:6: NOTICE:
-http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226
-cbbrowne at dba2:/tmp></screen>
-
-</warning>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/subscribenodes.xml (from rev 1244, traduc/trunk/slony/subscribenodes.xml)
===================================================================
--- traduc/tags/slony_1_2_12/subscribenodes.xml (rev 0)
+++ traduc/tags/slony_1_2_12/subscribenodes.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,159 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- DerniÚre modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="subscribenodes">
+<title>Enregistrement des serveurs</title>
+<indexterm><primary>Enregistrement des serveurs</primary></indexterm>
+
+<para>
+ Avant d'enregistrer un serveur à un ensemble, assurez-vous d'avoir un
+ processus <xref linkend="slon"/> pour chacune des deux parties à savoir le
+ fournisseur et pour le nouveau nœud de souscription. Si les démons slon
+ respectifs ne sont pas en cours d'exécution, alors il ne se passera rien et
+ vous vous éverturez à comprendre pourquoi cela ne fonctionne pas.
+</para>
+
+<para>
+ Ajouter un serveur à un ensemble de serveurs est fait en exécutant la commande
+ <xref linkend="stmtsubscribeset"/> de <xref linkend="slonik"/> . Il peut
+ sembler tentant d'essayer de souscrire plusieurs nœuds à un ensemble
+ dans un bloc d'essai simple comme celui-ci :
+
+<programlisting>
+try {
+ echo 'Subscribing sets';
+ subscrifbe set (id = 1, provider=1, receiver=2, forward=yes);
+ subscribe set (id = 1, provider=1, receiver=3, forward=yes);
+ subscribe set (id = 1, provider=1, receiver=4, forward=yes);
+} on error {
+ echo 'Enregistrement du jeu des serveurs : impossible!';
+ exit -1;
+}
+</programlisting>
+</para>
+
+<para>
+ Mais vous êtes juste en train de vous demander quel est le souci en
+ enregistrant les ensembles de serveurs de cette façon. La méthode
+ appropriée exige de procéder à l'enregistrement des serveurs, à raison
+ d'un seul à la fois, tout en examinant le journal de l'instance de la
+ base de donnée, avant de vous occuper du prochain enregistrement. Il est
+ également intéressant de noter que le <quote>succès</quote> dans l'essai
+ <xref linkend="slonik"/> ci-dessus, n'implique pas que les nœuds 2,
+ 3, et 4 soient tous enregistrés avec succès. Il indique simplement que les
+ commandes de slonik ont été reçues avec succès le démon
+ <application>slon</application> fonctionnant sur le nœud d'origine.
+</para>
+
+<para>
+ Un cas typique de problème pouvant surgir est qu'un abonné en cascade,
+ recherche un fournisseur qui n'est pas encore prêt. Dans ce cas d'échec, le
+ nœud souscripteur ne deviendra <emphasis>jamais</emphasis> l'abonné.
+ Il sera <quote>bloquée</quote> en attente d'un évènement déjà survenu.
+ Les autres nœuds seront persuadés que, ce nœud bloqué s'est
+ enregistré correctement (parce qu'aucune erreur ne leur est parvenu) ;
+ la demande pour désabonner le nœud sera <quote>bloqué</quote> car le
+ nœud en question est coincé en attente d'enregistrement.
+</para>
+
+<para>
+ Lorsque vous enregistrez un nœud à un ensemble de nœuds, vous
+ devez voir quelque chose de ce genre dans les traces du démon
+ <application>slon</application> pour le nœud fournisseur :
+
+<screen>
+DEBUG2 remoteWorkerThread_3: Received event 3,1059 SUBSCRIBE_SET
+</screen>
+</para>
+
+<para>
+ Vous devriez également commencer à voir des messages de ce genre dans les
+ traces du démon <application>slon</application> pour le nœud de
+ souscription :
+
+<screen>
+DEBUG2 remoteWorkerThread_1: copy table public.my_table
+</screen>
+</para>
+
+<para>
+ La copie de grandes tables entre le nœud de fournisseur et le nouvel
+ abonné peut prendre un certain temps. Si vous vérifiez la table
+ pg_stat_activity sur le nœud du fournisseur, vous devriez voir une
+ requête qui copie la table vers stdout.
+</para>
+
+<para>
+ La table <envar>sl_subscribe</envar> pour le fournisseur comme pour le
+ nouveau souscripteur, doit contenir un enregistrement pour le nouveau
+ abonnement :
+
+<screen>
+ sub_set | sub_provider | sub_receiver | sub_forward | sub_active
+---------+--------------+--------------+-------------+------------
+ 1 | 1 | 2 | t | t
+</screen>
+</para>
+
+<para>
+ Un ultime test est d'insérer un enregistrement dans une des tables répliquées
+ depuis le nœud d'origine, et de vérifier que cet enregistrement est bien
+ répliqué chez le souscripteur.
+</para>
+
+<warning>
+ <para>
+ Si vous créez et souscrivez à un ensemble de nœud qui ne contient
+ aucune table, cela peut mener à une situation qui empêchera la réplication
+ de se faire.
+ </para>
+
+ <para>
+ Notez que ce bug est corrigé depuis la version 1.1.5.
+ </para>
+
+ <para>
+ Si un abonné particulier est seulement alimenté par une séquence d'ordre
+ d'un de ces fournisseurs, la requête qui collecte l'évènement
+ <command>SYNC</command> ne sera pas correctement créée, et vous pouvez
+ voir une erreur similaire celle-ci :
+ </para>
+
+ <screen>2005-04-13 07:11:28 PDT ERROR remoteWorkerThread_11: "declare LOG
+cursor for select log_origin, log_xid, log_tableid, log_actionseq,
+log_cmdtype, log_cmddata from "_T1".sl_log_1 where log_origin = 11 and
+( order by log_actionseq; " PGRES_FATAL_ERROR ERROR: syntax error at
+or near "order" at character 162</screen>
+
+ <para>
+ La fonction <xref
+ linkend="function.subscribeset-integer-integer-integer-boolean"/> va
+ générer un avertissement si un ensemble de réplication donné ne contient
+ aucune table à répliquer, comme l'exemple suivant le montre :
+ </para>
+
+ <screen>cbbrowne at dba2:/tmp> cat create_empty_set.slonik
+cluster name = T1;
+node 11 admin conninfo = 'dbname=slony_test1';
+node 22 admin conninfo = 'dbname=slony_test2';
+
+create set (id = 255, origin = 11, comment='blank empty set');
+subscribe set (id=255, provider = 11, receiver = 22, forward = false);</screen>
+
+ <para>
+ Ceci mène au message d'avertissement suivant :
+ </para>
+
+ <screen>bbrowne at dba2:/tmp> slonik create_empty_set.slonik
+create_empty_set.slonik:6: NOTICE: subscribeSet:: set 255 has no tables
+- risk of problems - see bug 1226
+create_empty_set.slonik:6: NOTICE:
+http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226
+cbbrowne at dba2:/tmp></screen>
+
+</warning>
+
+</sect1>
Deleted: traduc/tags/slony_1_2_12/supportedplatforms.xml
===================================================================
--- traduc/trunk/slony/supportedplatforms.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/supportedplatforms.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,200 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="supportedplatforms">
-<title>Plate-formes supportées par &slony1;</title>
-<indexterm><primary>Plateformes supportées</primary></indexterm>
-
-<para>
- Lefonctionnement de &slony1; a été vérifié sur les plate-formes listée
- ci-dessous. &slony1; peut être compilé, installé et éxécuté avec succès
- sur ces plate-formes.
-</para>
-
-<para>Dernière mise à jour : 23 juin 2005</para>
-
-<para>
- Si vous rencontrez des problèmes sur une de ces plate-formes, s'il-vous-plait,
- inscrivez-vous à la <ulink
- url="http://gborg.PostgreSQL.org/mailman/listinfo/slony1-general">liste de
- discussions Slony-I</ulink> et posez vos questions.
-</para>
-
- <table id="platform-table">
- <title>Plate-formes supportées</title>
-
- <tgroup cols="6">
- <thead>
- <row>
- <entry>Système d'exploitation</entry>
- <entry>Version</entry>
- <entry>Type de processeur</entry>
- <entry>Date du dernier rapport</entry>
- <entry>Rapporté par</entry>
- <entry>Remarques</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry>Fedora Core</entry>
- <entry>3</entry>
- <entry>Intel - 32 bit</entry>
- <entry>22 juin 2005</entry>
- <entry>dvdm AROBASE truteq.co.za</entry>
- <entry>&postgres; version 7.4.6</entry>
- </row>
-
- <row>
- <entry>Red Hat Linux</entry>
- <entry>9</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>dvdm AROBASE truteq.co.za</entry>
- <entry>&postgres; version 7.4.5</entry>
- </row>
-
- <row>
- <entry>Debian GNU/Linux</entry>
- <entry>Sid</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; version 7.4.8</entry>
- </row>
-
- <row>
- <entry>Debian GNU/Linux</entry>
- <entry>Sid</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; version 8.0.2</entry>
- </row>
-
- <row>
- <entry>Debian GNU/Linux</entry>
- <entry>Sid</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; version 7.3.9</entry>
- </row>
-
- <row>
- <entry>AIX</entry>
- <entry>5.1</entry>
- <entry>PPC</entry>
- <entry>22 juin 2005</entry>
- <entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; version 7.4.8</entry>
- </row>
-
- <row>
- <entry>SunOS (a.k.a. Solaris8)</entry>
- <entry>5.8</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; version 7.4.8</entry>
- </row>
-
- <row>
- <entry>Red Hat Enterprise Linux Enterprise Server</entry>
- <entry>3.0</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
- NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
- alors il faut utiliser les RPM de la communauté</entry>
- </row>
-
- <row>
- <entry>Red Hat Enterprise Linux Enterprise Server</entry>
- <entry>4</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
- NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
- alors il faut utiliser les RPM de la communauté</entry>
- </row>
-
- <row>
- <entry>Fedora Core</entry>
- <entry>3</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
- NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
- alors il faut utiliser les RPM de la communauté</entry>
- </row>
-
- <row>
- <entry>Fedora Core</entry>
- <entry>4</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
- NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
- alors il faut utiliser les RPM de la communauté</entry>
- </row>
-
- <row>
- <entry>Red Hat Linux</entry>
- <entry>9</entry>
- <entry>x86</entry>
- <entry>14 juillet 2005</entry>
- <entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
- NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
- alors il faut utiliser les RPM de la communauté</entry>
- </row>
-
- <row>
- <entry>FreeBSD</entry>
- <entry>5.X</entry>
- <entry>AMD64</entry>
- <entry>1er juillet 2005</entry>
- <entry>stefan AROBASE kaltenbrunner.cc </entry>
- <entry>&postgres; version 8.0.3</entry>
- </row>
-
- <row>
- <entry>OpenBSD</entry>
- <entry>3.7</entry>
- <entry>Sparc64</entry>
- <entry>1er juillet 2005</entry>
- <entry>stefan AROBASE kaltenbrunner.cc </entry>
- <entry>&postgres; version 8.0.3</entry>
- </row>
-
- <row>
- <entry>OpenBSD</entry>
- <entry>3.7</entry>
- <entry>x86</entry>
- <entry>1er juillet 2005</entry>
- <entry>stefan AROBASE kaltenbrunner.cc </entry>
- <entry>&postgres; version 8.0.3</entry>
- </row>
-
- <row>
- <entry><trademark>Windows</trademark></entry>
- <entry>2000/XP/2003</entry>
- <entry>x86</entry>
- <entry>21 septembre 2006</entry>
- <entry>dpage AROBASE postgresql.org </entry>
- <entry>&postgres; version 8.1, 8.2</entry>
- </row>
-
- </tbody>
- </tgroup>
- </table>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/supportedplatforms.xml (from rev 1244, traduc/trunk/slony/supportedplatforms.xml)
===================================================================
--- traduc/tags/slony_1_2_12/supportedplatforms.xml (rev 0)
+++ traduc/tags/slony_1_2_12/supportedplatforms.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,227 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="supportedplatforms">
+<title>Plate-formes supportées par &slony1;</title>
+<indexterm><primary>Plateformes supportées</primary></indexterm>
+
+<para>
+ Lefonctionnement de &slony1; a été vérifié sur les plate-formes listée
+ ci-dessous. &slony1; peut être compilé, installé et éxécuté avec succès
+ sur ces plate-formes.
+</para>
+
+<para>Dernière mise à jour : 17 novembre 2006</para>
+
+<para>
+ Si vous rencontrez des problèmes sur une de ces plate-formes, s'il-vous-plait,
+ inscrivez-vous à la <ulink
+ url="http://gborg.PostgreSQL.org/mailman/listinfo/slony1-general">liste de
+ discussions Slony-I</ulink> et posez vos questions.
+</para>
+
+ <table id="platform-table">
+ <title>Plate-formes supportées</title>
+
+ <tgroup cols="6">
+ <thead>
+ <row>
+ <entry>Système d'exploitation</entry>
+ <entry>Version</entry>
+ <entry>Type de processeur</entry>
+ <entry>Date du dernier rapport</entry>
+ <entry>Rapporté par</entry>
+ <entry>Remarques</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry>Fedora Core</entry>
+ <entry>3</entry>
+ <entry>Intel - 32 bit</entry>
+ <entry>22 juin 2005</entry>
+ <entry>dvdm AROBASE truteq.co.za</entry>
+ <entry>&postgres; version 7.4.6</entry>
+ </row>
+
+ <row>
+ <entry>Red Hat Linux</entry>
+ <entry>9</entry>
+ <entry>x86</entry>
+ <entry>22 juin 2005</entry>
+ <entry>dvdm AROBASE truteq.co.za</entry>
+ <entry>&postgres; version 7.4.5</entry>
+ </row>
+
+ <row>
+ <entry>Debian GNU/Linux</entry>
+ <entry>Sid</entry>
+ <entry>x86</entry>
+ <entry>22 juin 2005</entry>
+ <entry>cbbrowne AROBASE ca.afilias.info</entry>
+ <entry>&postgres; version 7.4.8</entry>
+ </row>
+
+ <row>
+ <entry>Debian GNU/Linux</entry>
+ <entry>Sid</entry>
+ <entry>x86</entry>
+ <entry>22 juin 2005</entry>
+ <entry>cbbrowne AROBASE ca.afilias.info</entry>
+ <entry>&postgres; version 8.0.2</entry>
+ </row>
+
+ <row>
+ <entry>Debian GNU/Linux</entry>
+ <entry>Sid</entry>
+ <entry>x86</entry>
+ <entry>22 juin 2005</entry>
+ <entry>cbbrowne AROBASE ca.afilias.info</entry>
+ <entry>&postgres; version 7.3.9</entry>
+ </row>
+
+ <row>
+ <entry>AIX</entry>
+ <entry>5.1</entry>
+ <entry>PPC</entry>
+ <entry>22 juin 2005</entry>
+ <entry>cbbrowne AROBASE ca.afilias.info</entry>
+ <entry>&postgres; version 7.4.8</entry>
+ </row>
+
+ <row>
+ <entry>SunOS (a.k.a. Solaris8)</entry>
+ <entry>5.8</entry>
+ <entry>x86</entry>
+ <entry>22 juin 2005</entry>
+ <entry>cbbrowne AROBASE ca.afilias.info</entry>
+ <entry>&postgres; version 7.4.8</entry>
+ </row>
+
+ <row>
+ <entry>Red Hat Enterprise Linux Enterprise Server</entry>
+ <entry>3.0</entry>
+ <entry>x86</entry>
+ <entry>22 juin 2005</entry>
+ <entry>devrim AROBASE gunduz.org</entry>
+ <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
+ NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
+ alors il faut utiliser les RPM de la communauté</entry>
+ </row>
+
+ <row>
+ <entry>Red Hat Enterprise Linux Enterprise Server</entry>
+ <entry>4</entry>
+ <entry>x86</entry>
+ <entry>22 juin 2005</entry>
+ <entry>devrim AROBASE gunduz.org</entry>
+ <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
+ NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
+ alors il faut utiliser les RPM de la communauté</entry>
+ </row>
+
+ <row>
+ <entry>Fedora Core</entry>
+ <entry>3</entry>
+ <entry>x86</entry>
+ <entry>22 juin 2005</entry>
+ <entry>devrim AROBASE gunduz.org</entry>
+ <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
+ NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
+ alors il faut utiliser les RPM de la communauté</entry>
+ </row>
+
+ <row>
+ <entry>Fedora Core</entry>
+ <entry>4</entry>
+ <entry>x86</entry>
+ <entry>22 juin 2005</entry>
+ <entry>devrim AROBASE gunduz.org</entry>
+ <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
+ NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
+ alors il faut utiliser les RPM de la communauté</entry>
+ </row>
+
+ <row>
+ <entry>Fedora Core</entry>
+ <entry>5</entry>
+ <entry>x86</entry>
+ <entry>Nov 17, 2006</entry>
+ <entry>devrim at CommandPrompt.com</entry>
+ <entry>&postgres; Version: 8.1.5</entry>
+ </row>
+
+ <row>
+ <entry>Fedora Core</entry>
+ <entry>6</entry>
+ <entry>x86</entry>
+ <entry>Nov 17, 2006</entry>
+ <entry>devrim at CommandPrompt.com</entry>
+ <entry>&postgres; Version: 8.1.5</entry>
+ </row>
+
+ <row>
+ <entry>Fedora Core</entry>
+ <entry>6</entry>
+ <entry>x86_64</entry>
+ <entry>Nov 17, 2006</entry>
+ <entry>devrim at CommandPrompt.com</entry>
+ <entry>&postgres; Version: 8.1.5</entry>
+ </row>
+
+ <row>
+ <entry>Red Hat Linux</entry>
+ <entry>9</entry>
+ <entry>x86</entry>
+ <entry>14 juillet 2005</entry>
+ <entry>devrim AROBASE gunduz.org</entry>
+ <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
+ NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
+ alors il faut utiliser les RPM de la communauté</entry>
+ </row>
+
+ <row>
+ <entry>FreeBSD</entry>
+ <entry>5.X</entry>
+ <entry>AMD64</entry>
+ <entry>1er juillet 2005</entry>
+ <entry>stefan AROBASE kaltenbrunner.cc </entry>
+ <entry>&postgres; version 8.0.3</entry>
+ </row>
+
+ <row>
+ <entry>OpenBSD</entry>
+ <entry>3.7</entry>
+ <entry>Sparc64</entry>
+ <entry>1er juillet 2005</entry>
+ <entry>stefan AROBASE kaltenbrunner.cc </entry>
+ <entry>&postgres; version 8.0.3</entry>
+ </row>
+
+ <row>
+ <entry>OpenBSD</entry>
+ <entry>3.7</entry>
+ <entry>x86</entry>
+ <entry>1er juillet 2005</entry>
+ <entry>stefan AROBASE kaltenbrunner.cc </entry>
+ <entry>&postgres; version 8.0.3</entry>
+ </row>
+
+ <row>
+ <entry><trademark>Windows</trademark></entry>
+ <entry>2000/XP/2003</entry>
+ <entry>x86</entry>
+ <entry>21 septembre 2006</entry>
+ <entry>dpage AROBASE postgresql.org </entry>
+ <entry>&postgres; version 8.1, 8.2</entry>
+ </row>
+
+ </tbody>
+ </tgroup>
+ </table>
+
+</sect1>
Deleted: traduc/tags/slony_1_2_12/testbed.xml
===================================================================
--- traduc/trunk/slony/testbed.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/testbed.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,428 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="testbed">
-<title>Banc d'essai &slony1;</title>
-<indexterm><primary>plate-forme de tests</primary></indexterm>
-
-<para>
- Jusqu'à la version 1.1.5, &slony1; dispose d'une plate-forme commune de tests
- afin d'exécuter un ensemble compréhensible de tests de manière relativement
- automatique. Les anciens tests étaient réalisés avec
- <application>pgbench</application> (ce qui n'est pas une
- <emphasis>mauvaise</emphasis> chose en soi) mais étaient difficiles à
- automatiser car ils devaient être déployés sur chaque &lslon; dans un
- <application>xterm</application> afin que l'utilisateur puisse
- <emphasis>surveiller</emphasis>.
-</para>
-
-<para>
- La nouvelle plate-forme de test est principalement écrite en shell Bourne.
- Elle est conçue pour être portable sous bash (largement répandu sous Linux)
- et en Korn shell (que l'on retrouve souvent sur les systèmes UNIX
- commerciaux). Le code se trouve dans l'arborescence des sources au sein du
- répertoire <filename>tests</filename>.
-</para>
-
-<para>
- À présent, presque tous les tests font appel à seulement deux bases de
- données qui par défaut sont sur un postmaster &postgres; unique sur un seul
- serveur hôte. Ceci est parfait pour les tests qui impliquent la vérification
- des fonctions &slony1; pour divers types de données. Ces tests font des
- choses tels que varier les styles de date, et créer des tables et des
- séquences qui impliquent des noms inhabituels afin de vérifier que les
- guillemets sont gérés correctement.
-</para>
-
-<para>
- Il est également possible de configurer des variables d'environnement afin
- que les nœuds de la réplication soient placés sur différents serveurs
- de base de données, éventuellement sur des serveurs hôtes distants, utilisant
- différentes versions de &postgres;.
-</para>
-
-<para>
- Voici quelques-uns des fichiers vitaux :
-</para>
-
-
-<itemizedlist>
- <listitem>
- <para>
- <filename>run_test.sh</filename>
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Ceci est le script central pour exécuter les tests. Son utilisation typique
- est la suivante :
-</para>
-
-<para>
- <command>./run_test.sh</command>
-</para>
-
-<screen>
-usage ./run_test.sh nom_du_test
-</screen>
-
-<para>
- Vous devez spécifier le nom du sous-répertoire dans lequel l'ensemble du test
- sera réalisé ; chaque ensemble est stocké dans un sous-répertoire de
- <filename>tests</filename>.
-</para>
-
-<para>
- Vous pouvez définir une ou plusieurs variables d'environnement pour préciser
- votre configuration locale. Par exemple, on exécute <quote>test1</quote> sur
- &postgres; 8.0.x en utilisant la commande suivante :
-</para>
-
-<screen>PGBINDIR=/opt/OXRS/dbs/pgsql8/bin PGPORT=5532 PGUSER=cbbrowne ./run_test.sh test1</screen>
-
-<glosslist>
- <glossentry>
- <glossterm><envar>PGBINDIR</envar></glossterm>
-
- <glossdef>
- <para>
- Ceci détermine où les scripts de tests doivent chercher les binaires
- &postgres; et &slony1;. La valeur par défaut est
- <filename>/usr/local/pgsql/bin</filename>.
- </para>
-
- <para>
- Il existe également les variables <envar>PGBINDIR1</envar> jusqu'à
- <envar>PGBINDIR13</envar> qui permettent de définir un chemin spécifique
- pour chaque instance de base de données. C'est particulièrement utile
- lorsqu'on teste l'inter-opérabilité de &slony1; sur différentes versions
- de &postgres; et sur différentes plates-formes. Afin de créer une base de
- données de chaque version respective, vous devez pointer vers un
- <application>initdb</application> de la version appropriée.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>PGPORT</envar></glossterm>
-
- <glossdef>
- <para>
- Ceci indique sur quel port le processus postmaster écoute. Par défaut,
- le port 5432 est utilisé.
- </para>
-
- <para>
- Il existe également des variables <envar>PORT1</envar> jusqu'à
- <envar>PORT13</envar> qui permettent de spécifier un numéro de port
- pour chaque instance de base de données. Cela sera particulièrement
- utile lorsqu'on teste l'inter-opérabilité de &slony1; sur différentes
- versions de &postgres;.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>PGUSER</envar></glossterm>
-
- <glossdef>
- <para>
- Par défaut, l'utilisateur <filename>postgres</filename> est
- utilisé ; ceci est utilisé comme l'identifiant par défaut à
- utiliser sur toutes les bases de données.
- </para>
-
- <para>
- Il existe également des variables <envar>USER1</envar> jusqu'à
- <envar>USER13</envar> qui permettent de spécifier un nom d'utilisateur
- différent pour chaque instance. Comme toujours avec &slony1;, l'utilisateur
- doit être un <quote>super-utilisateur</quote> &postgres;.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>WEAKUSER</envar></glossterm>
-
- <glossdef>
- <para>
- Par défaut, l'utilisateur <filename>postgres</filename> est
- utilisé ; c'est utilisé par défaut comme l'identifiant de
- l'utilisateur pour les connexions <xref linkend="stmtstorepath"/>
- sur toutes les bases de données.
- </para>
-
- <para>
- Il existe également des variables <envar>WEAKUSER1</envar> jusqu'à
- <envar>WEAKUSER13</envar> qui permettent de spécifier différents noms
- d'utilisateur pour chaque instance. Cet utilisateur doit être un
- <quote>super-utilisateur</quote> &postgres;. Cet utilisateur peut
- commencer sans droits ; il obtient les droits de lecture sur les
- tables que le test utilise, ainsi que les droits d'accès sur le schéma
- &slony1;, et les droits d'écriture sur la table et la séquence
- utilisées pour gérer les verrous sur les nœuds.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>HOST</envar></glossterm>
-
- <glossdef>
- <para>
- Par défaut, <filename>localhost</filename> est utilisé.
- </para>
-
- <para>
- Il existe également les variables <envar>HOST1</envar> jusqu'à
- <envar>HOST13</envar> qui permettent de spécifier un hôte différent
- pour chaque instance de base de données.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>DB1</envar> jusqu'à <envar>DB13</envar></glossterm>
-
- <glossdef>
- <para>
- Par défaut, les valeurs<filename>slonyregress1</filename> jusqu'à
- <filename>slonyregress13</filename> sont utilisées.
- </para>
-
- <para>
- Vous pouvez surcharger cela depuis l'environnement si vous avez de
- bonnes raisons d'utiliser des noms différents.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>ENCODING</envar></glossterm>
-
- <glossdef>
- <para>
- Par défaut, <filename>UNICODE</filename> est utilisé, afin que les
- tests puissent créer des tables UTF8 et tester les capacités multibyte.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>MY_MKTEMP_IS_DECREPIT</envar></glossterm>
-
- <glossdef>
- <para>
- Si votre version de Linux utilise une version de
- <application>mktemp</application> qui ne génère pas un chemin absolu
- vers l'emplacement du fichier/répertoire temporaire, alors modifiez
- cette valeur.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>SLTOOLDIR</envar></glossterm>
-
- <glossdef>
- <para>
- Emplacement des outils &slony1; tels que
- <application>slony1_dump.sh</application>.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>ARCHIVE[n]</envar></glossterm>
-
- <glossdef>
- <para>
- Si cette option est positionnée à <quote>true</quote> pour un
- nœud donné, qui est normalement configurée automatiquement dans
- le fichier <filename>settings.ik</filename>, alors ce nœud sera
- utilisé comme source de données pour du <xref linkend="logshipping"/>,
- et cela impliquera que les outils de tests créeront le répertoire
- <link linkend="slon-config-archive-dir">archive_dir</link>.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>LOGSHIP[n]</envar></glossterm>
-
- <glossdef>
- <para>
- Si cette option est positionnée à <quote>true</quote> pour un
- nœud donné, qui est normalement configurée automatiquement dans
- le fichier <filename>settings.ik</filename>, alors ce nœud est
- créé via <xref linkend="logshipping"/>, et &lslon; n'est pas nécessaire
- pour ce nœud.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>SLONCONF[n]</envar></glossterm>
-
- <glossdef>
- <para>
- Si cette valeur est positionnée à <quote>true</quote> pour un nœud
- donnée qui est généralement configurée dans le fichier
- <filename>settings.ik</filename> pour un test donné, alors la
- <link linkend="runtime-config">configuration</link> sera placée dans un
- un fichier de configuration <filename>slon.conf</filename> spécifique
- pour chaque nœud.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>SLONYTESTER</envar></glossterm>
-
- <glossdef>
- <para>
- Adresse e-mail de la personne qui reçoit les résultats des tests.
- Ceci est stocké dans <envar>SLONYTESTFILE</envar> et peut être agrégé
- dans un registre comparable à une ferme de compilation.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>SLONYTESTFILE</envar></glossterm>
-
- <glossdef>
- <para>
- Fichier dans lequel sont stockés les résultats des tests. Ces résultats
- peuvent être utilisés pour construire un dépôt contenant l'agrégation
- des résultats de test.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm>
- <filename>random_number</filename> et <filename>random_string</filename>
- </glossterm>
-
- <glossdef>
- <para>
- Si vous exécutez <command>make</command> dans le répertoire de
- <filename>test</filename>, les programmes C
- <application>random_number</application> et
- <application>random_string</application> seront compilés et seront
- ensuite utilisés lors de la génération de données aléatoires au lieu
- d'utiliser les fonctions shell/SQL qui sont beaucoup plus lentes que
- les programmes C.
- </para>
- </glossdef>
- </glossentry>
-</glosslist>
-
-<para>
- Pour chaque test, vous trouverez les fichiers suivants :
-</para>
-
-<itemizedlist>
- <listitem>
- <para><filename>README</filename></para>
-
- <para>
- Ce fichier contient une description du test et est affiché au lecteur
- lorsque le test est invoqué.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>generate_dml.sh</filename></para>
-
- <para>
- Contient le code du script qui génère le SQL pour réaliser les mises à
- jour.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>init_add_tables.ik</filename></para>
-
- <para>
- Script <xref linkend="slonik"/> pour ajouter les tables pour le test de
- réplication.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>init_cluster.ik</filename></para>
-
- <para>
- Script <xref linkend="slonik"/> pour initialiser le cluster pour le test.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>init_create_set.ik</filename></para>
-
- <para>
- Script <xref linkend="slonik"/> pour initialiser les nœuds
- supplémentaires qui seront utilisés dans le test.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>init_schema.sql</filename></para>
-
- <para>
- Script SQL pour créer les tables et les séquences nécessaires au démarrage
- du test.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>init_data.sql</filename></para>
-
- <para>
- Script SQL pour initialiser le schéma dans l'état nécessaire sur le
- nœud <quote>maître</quote>.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>init_subscribe_set.ik</filename></para>
-
- <para>
- Script <xref linkend="slonik"/> pour mettre en place les abonnements.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>settings.ik</filename></para>
-
- <para>
- Script shell utilisé pour contrôler la taille du cluster, comment les
- nœuds seront créés, et où se trouve l'origine.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>schema.diff</filename></para>
-
- <para>
- Série de requêtes SQL, une par ligne, qui sont utilisés pour valider que
- les données se correspondent sur tous les nœuds. Notez qu'afin
- d'éviter des échecs inutiles, les requêtes doivent utiliser des clauses
- <command>ORDER BY</command> non-ambigües.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Pour d'éventuels tests additionnels, tels que l'utilisation de <xref
- linkend="stmtddlscript"/>, des scripts <xref linkend="slonik"/> et SQL
- supplémentaires pourront être nécessaires.
-</para>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/testbed.xml (from rev 1244, traduc/trunk/slony/testbed.xml)
===================================================================
--- traduc/tags/slony_1_2_12/testbed.xml (rev 0)
+++ traduc/tags/slony_1_2_12/testbed.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,371 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="testbed">
+<title>Banc d'essai &slony1;</title>
+<indexterm><primary>plate-forme de tests</primary></indexterm>
+
+<para>
+ Jusqu'à la version 1.1.5, &slony1; dispose d'une plate-forme commune de tests
+ afin d'exécuter un ensemble compréhensible de tests de manière relativement
+ automatique. Les anciens tests étaient réalisés avec
+ <application>pgbench</application> (ce qui n'est pas une
+ <emphasis>mauvaise</emphasis> chose en soi) mais étaient difficiles à
+ automatiser car ils devaient être déployés sur chaque &lslon; dans un
+ <application>xterm</application> afin que l'utilisateur puisse
+ <emphasis>surveiller</emphasis>.
+</para>
+
+<para>
+ La nouvelle plate-forme de test est principalement écrite en shell Bourne.
+ Elle est conçue pour être portable sous bash (largement répandu sous Linux)
+ et en Korn shell (que l'on retrouve souvent sur les systèmes UNIX
+ commerciaux). Le code se trouve dans l'arborescence des sources au sein du
+ répertoire <filename>tests</filename>.
+</para>
+
+<para>
+ À présent, presque tous les tests font appel à seulement deux bases de
+ données qui par défaut sont sur un postmaster &postgres; unique sur un seul
+ serveur hôte. Ceci est parfait pour les tests qui impliquent la vérification
+ des fonctions &slony1; pour divers types de données. Ces tests font des
+ choses tels que varier les styles de date, et créer des tables et des
+ séquences qui impliquent des noms inhabituels afin de vérifier que les
+ guillemets sont gérés correctement.
+</para>
+
+<para>
+ Il est également possible de configurer des variables d'environnement afin
+ que les nœuds de la réplication soient placés sur différents serveurs
+ de base de données, éventuellement sur des serveurs hôtes distants, utilisant
+ différentes versions de &postgres;.
+</para>
+
+<para>
+ Voici quelques-uns des fichiers vitaux :
+</para>
+
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <filename>run_test.sh</filename>
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Ceci est le script central pour exécuter les tests. Son utilisation typique
+ est la suivante :
+</para>
+
+<para>
+ <command>./run_test.sh</command>
+</para>
+
+<screen>
+usage ./run_test.sh nom_du_test
+</screen>
+
+<para>
+ Vous devez spécifier le nom du sous-répertoire dans lequel l'ensemble du test
+ sera réalisé ; chaque ensemble est stocké dans un sous-répertoire de
+ <filename>tests</filename>.
+</para>
+
+<para>
+ Vous pouvez définir une ou plusieurs variables d'environnement pour préciser
+ votre configuration locale. Par exemple, on exécute <quote>test1</quote> sur
+ &postgres; 8.0.x en utilisant la commande suivante :
+</para>
+
+<screen>PGBINDIR=/opt/OXRS/dbs/pgsql8/bin PGPORT=5532 PGUSER=cbbrowne ./run_test.sh test1</screen>
+
+<glosslist>
+ <glossentry>
+ <glossterm><envar>PGBINDIR</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Ceci détermine où les scripts de tests doivent chercher les binaires
+ &postgres; et &slony1;. La valeur par défaut est
+ <filename>/usr/local/pgsql/bin</filename>.
+ </para>
+
+ <para>
+ Il existe également les variables <envar>PGBINDIR1</envar> jusqu'à
+ <envar>PGBINDIR13</envar> qui permettent de définir un chemin spécifique
+ pour chaque instance de base de données. C'est particulièrement utile
+ lorsqu'on teste l'inter-opérabilité de &slony1; sur différentes versions
+ de &postgres; et sur différentes plates-formes. Afin de créer une base de
+ données de chaque version respective, vous devez pointer vers un
+ <application>initdb</application> de la version appropriée.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm><envar>PGPORT</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Ceci indique sur quel port le processus postmaster écoute. Par défaut,
+ le port 5432 est utilisé.
+ </para>
+
+ <para>
+ Il existe également des variables <envar>PORT1</envar> jusqu'à
+ <envar>PORT13</envar> qui permettent de spécifier un numéro de port
+ pour chaque instance de base de données. Cela sera particulièrement
+ utile lorsqu'on teste l'inter-opérabilité de &slony1; sur différentes
+ versions de &postgres;.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm><envar>PGUSER</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Par défaut, l'utilisateur <filename>postgres</filename> est
+ utilisé ; ceci est utilisé comme l'identifiant par défaut à
+ utiliser sur toutes les bases de données.
+ </para>
+
+ <para>
+ Il existe également des variables <envar>USER1</envar> jusqu'à
+ <envar>USER13</envar> qui permettent de spécifier un nom d'utilisateur
+ différent pour chaque instance. Comme toujours avec &slony1;, l'utilisateur
+ doit être un <quote>super-utilisateur</quote> &postgres;.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm><envar>WEAKUSER</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Par défaut, l'utilisateur <filename>postgres</filename> est
+ utilisé ; c'est utilisé par défaut comme l'identifiant de
+ l'utilisateur pour les connexions <xref linkend="stmtstorepath"/>
+ sur toutes les bases de données.
+ </para>
+
+ <para>
+ Il existe également des variables <envar>WEAKUSER1</envar> jusqu'à
+ <envar>WEAKUSER13</envar> qui permettent de spécifier différents noms
+ d'utilisateur pour chaque instance. Cet utilisateur doit être un
+ <quote>super-utilisateur</quote> &postgres;. Cet utilisateur peut
+ commencer sans droits ; il obtient les droits de lecture sur les
+ tables que le test utilise, ainsi que les droits d'accès sur le schéma
+ &slony1;, et les droits d'écriture sur la table et la séquence
+ utilisées pour gérer les verrous sur les nœuds.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm><envar>HOST</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Par défaut, <filename>localhost</filename> est utilisé.
+ </para>
+
+ <para>
+ Il existe également les variables <envar>HOST1</envar> jusqu'à
+ <envar>HOST13</envar> qui permettent de spécifier un hôte différent
+ pour chaque instance de base de données.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm><envar>DB1</envar> jusqu'à <envar>DB13</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Par défaut, les valeurs<filename>slonyregress1</filename> jusqu'à
+ <filename>slonyregress13</filename> sont utilisées.
+ </para>
+
+ <para>
+ Vous pouvez surcharger cela depuis l'environnement si vous avez de
+ bonnes raisons d'utiliser des noms différents.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm><envar>ENCODING</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Par défaut, <filename>UNICODE</filename> est utilisé, afin que les
+ tests puissent créer des tables UTF8 et tester les capacités multibyte.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm><envar>MY_MKTEMP_IS_DECREPIT</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Si votre version de Linux utilise une version de
+ <application>mktemp</application> qui ne génère pas un chemin absolu
+ vers l'emplacement du fichier/répertoire temporaire, alors modifiez
+ cette valeur.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm><envar>SLTOOLDIR</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Emplacement des outils &slony1; tels que
+ <application>slony1_dump.sh</application>.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm><envar>ARCHIVE[n]</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Si cette option est positionnée à <quote>true</quote> pour un
+ nœud donné, qui est normalement configurée automatiquement dans
+ le fichier <filename>settings.ik</filename>, alors ce nœud sera
+ utilisé comme source de données pour du <xref linkend="logshipping"/>,
+ et cela impliquera que les outils de tests créeront le répertoire
+ <link linkend="slon-config-archive-dir">archive_dir</link>.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm><envar>LOGSHIP[n]</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Si cette option est positionnée à <quote>true</quote> pour un
+ nœud donné, qui est normalement configurée automatiquement dans
+ le fichier <filename>settings.ik</filename>, alors ce nœud est
+ créé via <xref linkend="logshipping"/>, et &lslon; n'est pas nécessaire
+ pour ce nœud.
+ </para>
+ </glossdef>
+ </glossentry>
+</glosslist>
+
+<para>
+ Pour chaque test, vous trouverez les fichiers suivants :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para><filename>README</filename></para>
+
+ <para>
+ Ce fichier contient une description du test et est affiché au lecteur
+ lorsque le test est invoqué.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>generate_dml.sh</filename></para>
+
+ <para>
+ Contient le code du script qui génère le SQL pour réaliser les mises à
+ jour.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>init_add_tables.ik</filename></para>
+
+ <para>
+ Script <xref linkend="slonik"/> pour ajouter les tables pour le test de
+ réplication.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>init_cluster.ik</filename></para>
+
+ <para>
+ Script <xref linkend="slonik"/> pour initialiser le cluster pour le test.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>init_create_set.ik</filename></para>
+
+ <para>
+ Script <xref linkend="slonik"/> pour initialiser les nœuds
+ supplémentaires qui seront utilisés dans le test.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>init_schema.sql</filename></para>
+
+ <para>
+ Script SQL pour créer les tables et les séquences nécessaires au démarrage
+ du test.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>init_data.sql</filename></para>
+
+ <para>
+ Script SQL pour initialiser le schéma dans l'état nécessaire sur le
+ nœud <quote>maître</quote>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>init_subscribe_set.ik</filename></para>
+
+ <para>
+ Script <xref linkend="slonik"/> pour mettre en place les abonnements.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>settings.ik</filename></para>
+
+ <para>
+ Script shell utilisé pour contrôler la taille du cluster, comment les
+ nœuds seront créés, et où se trouve l'origine.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>schema.diff</filename></para>
+
+ <para>
+ Série de requêtes SQL, une par ligne, qui sont utilisés pour valider que
+ les données se correspondent sur tous les nœuds. Notez qu'afin
+ d'éviter des échecs inutiles, les requêtes doivent utiliser des clauses
+ <command>ORDER BY</command> non-ambigües.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Pour d'éventuels tests additionnels, tels que l'utilisation de <xref
+ linkend="stmtddlscript"/>, des scripts <xref linkend="slonik"/> et SQL
+ supplémentaires pourront être nécessaires.
+</para>
+
+</sect1>
Deleted: traduc/tags/slony_1_2_12/usingslonik.xml
===================================================================
--- traduc/trunk/slony/usingslonik.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/tags/slony_1_2_12/usingslonik.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -1,444 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<sect1 id="usingslonik">
-<title>Utiliser Slonik</title>
-<indexterm><primary>utiliser slonik</primary></indexterm>
-
-<para>
- Il est parfois pénible d'écrire les scripts <application>Slonik</application>
- à la main, en particulier lorsqu'on travaille avec des clusters &slony1;
- dont le nombre de nœuds et d'ensemble de réplication augmente
- régulièrement. Les problèmes suivants ont été identifiés.
-</para>
-
-<itemizedlist>
-
- <listitem>
- <para>
- Si vous utilisez &slony1; pour une réplication
- <quote>maître/esclave</quote> avec un nœud <quote>maître</quote>
- et un nœud <quote>esclave</quote>, le plus simple est de nommer le
- nœud <quote>maître</quote> nœud 1 et le nœud
- <quote>esclave</quote> nœud 2.
- </para>
-
- <para>
- Malheureusement, lorsque le nombre de nœud augmente, la
- correspondance entre les identifiants et les nœuds devient moins
- évidente, en particulier si vous avez un cluster dont l'origine est
- déplacée d'un nœud à l'autre de temps en temps.
- </para>
- </listitem>
-
- <listitem>
- <para>
- De la même façon, s'il n'y a qu'un seul ensemble de réplication, il est
- facile de le nommer <quote>ensemble 1</quote> mais s'il y a de multiples
- ensembles, la numérotation des ensembles sera moins intuitive.
- </para>
- </listitem>
-
- <listitem>
- <para>
- On observe que <application>Slonik</application> ne fournit pas la notion
- d'itération. Il est courant de vouloir créer un ensemble d'entrées <xref
- linkend="stmtstorepath"/> similaires car, la plupart du temps, les hôtes
- accèdent à un serveur via le même nom d'hôte ou la même adresse IP.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Les utilisateurs semblent intéressés à tout insérer à l'intérieur de
- blocs <command>TRY</command>, ce qui n'est pas aussi utile qu'on pourrait
- le penser.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Certaines évolutions ont résolu une partie de ces problèmes :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>Nœuds nommés, ensemble nommés</para>
-
- <para>
- Ceci est supporté par les commandes <xref
- linkend="stmtdefine"/> et <xref linkend="stmtinclude"/> à partir de
- &slony1; 1.1.
- </para>
-
- <para>
- L'utilisation de <xref linkend="stmtinclude"/> pour créer des
- <quote>fichiers préambule</quote> est une méthode essentielle
- pour réduire les erreurs. Un fichier préambule est défini
- <emphasis>une seule fois</emphasis> et vérifié <emphasis>une seule
- fois</emphasis>. Ces fichiers peuvent être utilisés en tout confiance
- par les autres scripts slonik.
- </para>
- </listitem>
-
- <listitem>
- <para>Boucles et opérateurs de contrôle</para>
-
- <para>
- Il est inutile de créer un analyseur complet, c'est trop complexe. Il
- existe de nombreux langages de script que l'on peut utiliser pour
- construire des scripts Slonik ; il n'est pas intéressant d'en
- imposer un nouveau.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Il existe plusieurs façons de régler ces problèmes :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>Inclure la génération du script slonik dans un script shell</para>
-
- <para>
- Les tests trouvés dans le répertoire <filename>src/ducttape</filename>
- utilisent cette approche.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Les <link linkend="altperl">outils altperl</link> utilisent du code
- Perl pour générer les scripts Slonik.
- </para>
-
- <para>
- Vous définissez les configuration du cluster comme un ensemble d'objets
- Perl ; chaque script altperl utilise les objets Perl pour produire
- le script slonik adéquate.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect1>
-
-<sect1 id="slonikshell">
-<title>Utiliser Slonik à partir d'un script shell</title>
-<indexterm><primary>utiliser slonik à l'intérieur de scripts shell</primary></indexterm>
-
-<para>
- Comme on l'a vu précédemment, il existe de nombreux scripts de test pour
- &slony1; dans le répertoire <filename>src/ducttape</filename> qui intègre
- la génération de script Slonik à l'intérieur de code écrit en shell.
-</para>
-
-<para>
- La plupart de ces scripts ne sont <emphasis>pas</emphasis> terriblement
- sophistiqués. Typiquement, ils utilisent des structures comme celle-ci :
-
-<programlisting><![CDATA[
-DB1=slony_test1
-DB2=slony_test2
-slonik <<_EOF_
- cluster name = T1;
- node 1 admin conninfo = 'dbname=$DB1';
- node 2 admin conninfo = 'dbname=$DB2';
-
- try {
- create set (id = 1, origin = 1, comment =
- 'Set 1 - pgbench tables');
- set add table (set id = 1, origin = 1,
- id = 1, fully qualified name = 'public.accounts',
- comment = 'Table accounts');
- set add table (set id = 1, origin = 1,
- id = 2, fully qualified name = 'public.branches',
- comment = 'Table branches');
- set add table (set id = 1, origin = 1,
- id = 3, fully qualified name = 'public.tellers',
- comment = 'Table tellers');
- set add table (set id = 1, origin = 1,
- id = 4, fully qualified name = 'public.history',
- comment = 'Table accounts');
- }
- on error {
- exit 1;
- }
-_EOF_
-]]></programlisting></para>
-
-<para>
- Une approche plus sophistiquée consiste à définir des composants communs,
- notamment un <quote>préambule</quote> qui contient les commandes <xref
- linkend="clustername"/> et <xref linkend="admconninfo"/> que l'on
- retrouve dans chaque script Slonik :
-
-<programlisting>
-CLUSTER=T1
-DB1=slony_test1
-DB2=slony_test2
-PREAMBULE="cluster name = $CLUSTER
-node 1 admin conninfo = 'dbname=$DB1';
-node 2 admin conninfo = 'dbname=$DB2';
-"
-</programlisting></para>
-
-<para>
- La variable <envar>PREAMBULE</envar> peut alors être réutilisée plusieurs
- fois lorsque le script shell invoque plusieurs fois <command>slonik</command>.
- Vous pouvez également utiliser <xref linkend="stmtinclude"/> et placer le
- preambule dans un fichier que vous incluez.
-</para>
-
-<para>
- Les variables shell fournissent une méthode simple pour assigner les noms
- d'ensemble et de nœuds :
-</para>
-
-<programlisting><![CDATA[
-origin=1
-subscriber=2
-mainset=1
-slonik <<_EOF_
-$PREAMBULE
-try {
- create set (id = $mainset, origin = $origin,
- comment = 'Set $mainset - pgbench tables');
- set add table (set id = $mainset, origin = $origin,
- id = 1, fully qualified name = 'public.accounts',
- comment = 'Table accounts');
- set add table (set id = $mainset, origin = $origin,
- id = 2, fully qualified name = 'public.branches',
- comment = 'Table branches');
- set add table (set id = $mainset, origin = $origin,
- id = 3, fully qualified name = 'public.tellers',
- comment = 'Table tellers');
- set add table (set id = $mainset, origin = $origin,
- id = 4, fully qualified name = 'public.history',
- comment = 'Table accounts');
-} on error {
- exit 1;
-}
-_EOF_
-]]></programlisting>
-
-<para>
- Le script peut être utilisé en suite pour boucler sur la liste des
- tables :
-</para>
-
-<programlisting><![CDATA[
-# Basic configuration
-origin=1
-subscriber=2
-mainset=1
-# List of tables to replicate
-TABLES="accounts branches tellers history"
-ADDTABLES=""
-tnum=1
-for table in `echo $TABLES`; do
- ADDTABLES="$ADDTABLES
- set add table ($set id = $mainset, origin = $origin,
- id = $tnum, fully qualified name = 'public.$table',
- comment = 'Table $tname');
-"
- let "tnum=tnum+1"
-done
-slonik <<_EOF_
-$PREAMBULE
-try {
- create set (id = $mainset, origin = $origin,
- comment = 'Set $mainset - pgbench tables');
-$ADDTABLES
-} on error {
- exit 1;
-}
-_EOF_
-]]></programlisting>
-
-<para>
- Ce n'est peut-être pas nécessaire si vous n'avez que quatre tables mais cette
- méthode évite de recopier de longues listes de configuration à la main et
- préviendra les erreurs sur les grands ensembles que vous rencontrerez dans
- la <quote>vraie vie</quote>.
-</para>
-
-<para>
- Vous pouvez créer des scripts encore plus sophistiqués si votre langage de
- script possède :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- des structures de type <quote>Record</quote> qui permettent d'assigner
- des objets en parallèle ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- des fonctions, procédure ou des routines qui permettent d'implanter des
- fonctionnalités une seule fois, puis de les appeler à divers endroits
- de votre script.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Un mécanisme d'<quote>import de module</quote> afin de partager de
- fonctionnalités commune entre plusieurs scripts.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Si vous devez utiliser <ulink
- url="http://www.gnu.org/software/bash/bash.html">Bash</ulink>, <ulink
- url="http://www.zsh.org/">zsh</ulink> ou <ulink
- url="http://www.kornshell.com/">Korn shell</ulink>, tous ces shells possèdent
- des extensions qui gèrent correctement les structures de données
- sophistiquées et les modules. Sur linux, Bash est très répandu ; sur les
- systèmes <trademark>UNIX</trademark> commerciaux, Korn est le standard alors
- que sur BSD, les shells <quote>sophistiqués</quote> sont en option.
-</para>
-
-<para>
- N'oubliez pas de regarder du côté des des autres langages de script, parmi
- lesquels Perl est le plus évident, puisqu'il est largement répandu sur Linux,
- <trademark>UNIX</trademark> et BSD.
-</para>
-
-</sect1>
-
-<sect1 id="noslonik">
-<title>Ne pas utiliser Slonik - les fonctions &slony1; de bas niveau</title>
-<indexterm><primary>fonctions &slony1; de bas niveau</primary></indexterm>
-
-<para>
- Il est parfois nécessaire d'utiliser directement les procédures stockées
- qui composent les différentes parties de &slony1;. Slonik n'est pas
- <quote>magique</quote> ; il est courant qu'une commande Slonik se
- contente de décider le nœud qui va recevoir la commande et lui
- envoie une requête SQL qui contient une seule procédure stockée &slony1;.
-</para>
-
-<para>
- Les développeurs de &slony1; espèrent que quelqu'un développera des outils
- graphiques qui constitueront une alternative à Slonik ; il serait alors
- utile d'envoyer les ordres de configuration directement via les procédures
- stockées. Si vous comptez vous lancer dans ce projet, il est conseillé
- d'examiner comment les procédures stockées sont utilisées dans le fichier
- <filename>slonik.c</filename> puisqu'il s'agit de l'utilisation la plus
- correcte de ces fonctions.
-</para>
-
-<para>
- Lorsque qu'on corrige des problèmes sur un cluster &slony1;
- <quote>endommagé</quote>, il est parfois utile d'utiliser les procédures
- stockées. C'est particulièrement efficace lorsque la configuration de la table
- <xref linkend="table.sl-listen"/> est corrompue et que les événements ne se
- propagent plus correctement. La méthode la <quote>plus simple</quote> pour
- réparer cela est la suivante :
-</para>
-
-<para>
-
-<command>SELECT _slonycluster.droplisten(li_origin,li_provider,li_receiver)
-FROM _slonycluster.sl_listen;</command>
-
-</para>
-
-<para>
-
-<command>SELECT _slonycluster.storelisten(pa_server, pa_server, pa_client)
-FROM _slonycluster.sl_path;</command>
-
-</para>
-
-<para>
- Le résultat de ces requêtes est la regénération et la
- <emphasis>propagation</emphasis> des voies d'écoute. En lançant à la main la
- fonction <function> _slonycluster.storelisten()</function>, on déclenche des
- évènements <command>STORE_LISTEN</command> qui provoquent l'envoi des voies
- d'écoute sur les autres nœuds du cluster.
-</para>
-
-<para>
- En cas de problème <emphasis>local</emphasis> sur un nœud, si vous ne
- souhaitez pas propager les corrections (ce qui est assez rare, on cherche en
- général à réparer <emphasis>l'ensemble</emphasis> du cluster), la requête
- est la suivante :
-</para>
-
-<para><command>SELECT slonycluster.droplisten_int(li_origin,li_provider,li_receiver)
-FROM _slonycluster.sl_listen;</command></para>
-
-<para><command>SELECT _slonycluster.storelisten_int(pa_server, pa_server, pa_client)
-FROM_slonycluster.sl_path;</command></para>
-
-<para>
- Si vous souhaitez ajouter le support de &slony1; dans d'autres outils
- (<emphasis>par exemple :</emphasis> ajouter la réplication dans <ulink
- url="http://www.pgadmin.org/"><productname>pgAdmin III</productname></ulink>),
- vous devez savoir clairement quelles fonctions il faut appeler. Le
- <quote>protocole</quote> normal est le suivant :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- La fonction <quote>principale</quote> (<emphasis>par exemple</emphasis>
- celle sans le suffixe <command>_int</command>) est appelée sur un
- nœud <quote>adéquat</quote> du cluster &slony1;.
- </para>
-
- <para>
- Dans la plupart des cas, la fonction peut être appelée sur n'importe
- quel nœud, et elle propage correctement les commandes aux autres
- nœuds. C'est vrai pour <xref
- linkend="function.storelisten-integer-integer-integer"/>, par exemple.
- </para>
-
- <para>
- Dans d'autres cas, la fonction doit être lancée depuis un nœud
- particulier car c'est le seul endroit où les données sont valides.
- Par exemple, <xref
- linkend="function.subscribeset-integer-integer-integer-boolean"/> doit
- être appelée sur le nœud récepteur.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si la fonction <quote>principale</quote> réussit, alors le changement de
- configuration est effectué sur le nœud local et un événement est
- créé avec <xref linkend="function.createevent-name-text"/> pour que le
- changement de configuration soit propagé à tous les autres nœuds
- du cluster &slony1;.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Troisièmement, la version <command>_int</command> de la fonction doit
- être lancée.
- </para>
-
- <para>
- Dans certains cas, lorsque les fonctions sont idempotentes, le nœud
- sur lequel la fonction <quote>principale</quote> est exécutée peut traiter
- la version <command>_int</command> très tôt.
- </para>
-
- <para>
- Au moment où l'événement se propage, les nœuds lancent la version
- <command>_int</command>, en espérant que tout se passe bien.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect1>
Copied: traduc/tags/slony_1_2_12/usingslonik.xml (from rev 1244, traduc/trunk/slony/usingslonik.xml)
===================================================================
--- traduc/tags/slony_1_2_12/usingslonik.xml (rev 0)
+++ traduc/tags/slony_1_2_12/usingslonik.xml 2009-02-23 15:46:28 UTC (rev 1245)
@@ -0,0 +1,464 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modification
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<sect1 id="usingslonik">
+<title>Utiliser Slonik</title>
+<indexterm><primary>utiliser slonik</primary></indexterm>
+
+<para>
+ Il est parfois pénible d'écrire les scripts <application>Slonik</application>
+ à la main, en particulier lorsqu'on travaille avec des clusters &slony1;
+ dont le nombre de nœuds et d'ensemble de réplication augmente
+ régulièrement. Les problèmes suivants ont été identifiés.
+</para>
+
+<itemizedlist>
+
+ <listitem>
+ <para>
+ Si vous utilisez &slony1; pour une réplication
+ <quote>maître/esclave</quote> avec un nœud <quote>maître</quote>
+ et un nœud <quote>esclave</quote>, le plus simple est de nommer le
+ nœud <quote>maître</quote> nœud 1 et le nœud
+ <quote>esclave</quote> nœud 2.
+ </para>
+
+ <para>
+ Malheureusement, lorsque le nombre de nœud augmente, la
+ correspondance entre les identifiants et les nœuds devient moins
+ évidente, en particulier si vous avez un cluster dont l'origine est
+ déplacée d'un nœud à l'autre de temps en temps.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ De la même façon, s'il n'y a qu'un seul ensemble de réplication, il est
+ facile de le nommer <quote>ensemble 1</quote> mais s'il y a de multiples
+ ensembles, la numérotation des ensembles sera moins intuitive.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ On observe que <application>Slonik</application> ne fournit pas la notion
+ d'itération. Il est courant de vouloir créer un ensemble d'entrées <xref
+ linkend="stmtstorepath"/> similaires car, la plupart du temps, les hôtes
+ accèdent à un serveur via le même nom d'hôte ou la même adresse IP.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Les utilisateurs semblent intéressés à tout insérer à l'intérieur de
+ blocs <command>TRY</command>, ce qui n'est pas aussi utile qu'on pourrait
+ le penser.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Certaines évolutions ont résolu une partie de ces problèmes :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>Nœuds nommés, ensemble nommés</para>
+
+ <para>
+ Ceci est supporté par les commandes <xref
+ linkend="stmtdefine"/> et <xref linkend="stmtinclude"/> à partir de
+ &slony1; 1.1.
+ </para>
+
+ <para>
+ L'utilisation de <xref linkend="stmtinclude"/> pour créer des
+ <quote>fichiers préambule</quote> est une méthode essentielle
+ pour réduire les erreurs. Un fichier préambule est défini
+ <emphasis>une seule fois</emphasis> et vérifié <emphasis>une seule
+ fois</emphasis>. Ces fichiers peuvent être utilisés en tout confiance
+ par les autres scripts slonik.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Boucles et opérateurs de contrôle</para>
+
+ <para>
+ Il est inutile de créer un analyseur complet, c'est trop complexe. Il
+ existe de nombreux langages de script que l'on peut utiliser pour
+ construire des scripts Slonik ; il n'est pas intéressant d'en
+ imposer un nouveau.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Il existe plusieurs façons de régler ces problèmes :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>Inclure la génération du script slonik dans un script shell</para>
+
+ <para>
+ Les tests trouvés dans le répertoire <filename>src/ducttape</filename>
+ utilisent cette approche.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Les <link linkend="altperl">outils altperl</link> utilisent du code
+ Perl pour générer les scripts Slonik.
+ </para>
+
+ <para>
+ Vous définissez les configuration du cluster comme un ensemble d'objets
+ Perl ; chaque script altperl utilise les objets Perl pour produire
+ le script slonik adéquate.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect1>
+
+<sect1 id="slonikshell">
+<title>Utiliser Slonik à partir d'un script shell</title>
+<indexterm><primary>utiliser slonik à l'intérieur de scripts shell</primary></indexterm>
+
+<para>
+ Comme on l'a vu précédemment, il existe de nombreux scripts de test pour
+ &slony1; dans le répertoire <filename>src/ducttape</filename> qui intègre
+ la génération de script Slonik à l'intérieur de code écrit en shell.
+</para>
+
+<para>
+ La plupart de ces scripts ne sont <emphasis>pas</emphasis> terriblement
+ sophistiqués. Typiquement, ils utilisent des structures comme celle-ci :
+
+<programlisting><![CDATA[
+DB1=slony_test1
+DB2=slony_test2
+slonik <<_EOF_
+ cluster name = T1;
+ node 1 admin conninfo = 'dbname=$DB1';
+ node 2 admin conninfo = 'dbname=$DB2';
+
+ try {
+ table add key (node id = 1, fully qualified name =
+ 'public.history');
+ }
+ on error {
+ exit 1;
+ }
+
+ try {
+ create set (id = 1, origin = 1, comment =
+ 'Set 1 - pgbench tables');
+ set add table (set id = 1, origin = 1,
+ id = 1, fully qualified name = 'public.accounts',
+ comment = 'Table accounts');
+ set add table (set id = 1, origin = 1,
+ id = 2, fully qualified name = 'public.branches',
+ comment = 'Table branches');
+ set add table (set id = 1, origin = 1,
+ id = 3, fully qualified name = 'public.tellers',
+ comment = 'Table tellers');
+ set add table (set id = 1, origin = 1,
+ id = 4, fully qualified name = 'public.history',
+ key = serial, comment = 'Table accounts');
+ }
+ on error {
+ exit 1;
+ }
+_EOF_
+]]></programlisting></para>
+
+<para>
+ Une approche plus sophistiquée consiste à définir des composants communs,
+ notamment un <quote>préambule</quote> qui contient les commandes <xref
+ linkend="clustername"/> et <xref linkend="admconninfo"/> que l'on
+ retrouve dans chaque script Slonik :
+
+<programlisting>
+CLUSTER=T1
+DB1=slony_test1
+DB2=slony_test2
+PREAMBULE="cluster name = $CLUSTER
+node 1 admin conninfo = 'dbname=$DB1';
+node 2 admin conninfo = 'dbname=$DB2';
+"
+</programlisting></para>
+
+<para>
+ La variable <envar>PREAMBULE</envar> peut alors être réutilisée plusieurs
+ fois lorsque le script shell invoque plusieurs fois <command>slonik</command>.
+ Vous pouvez également utiliser <xref linkend="stmtinclude"/> et placer le
+ preambule dans un fichier que vous incluez.
+</para>
+
+<para>
+ Les variables shell fournissent une méthode simple pour assigner les noms
+ d'ensemble et de nœuds :
+</para>
+
+<programlisting><![CDATA[
+origin=1
+subscriber=2
+mainset=1
+slonik <<_EOF_
+$PREAMBULE
+try {
+ table add key (node id = $origin, fully qualified name =
+ 'public.history');
+} on error {
+ exit 1;
+}
+try {
+ create set (id = $mainset, origin = $origin,
+ comment = 'Set $mainset - pgbench tables');
+ set add table (set id = $mainset, origin = $origin,
+ id = 1, fully qualified name = 'public.accounts',
+ comment = 'Table accounts');
+ set add table (set id = $mainset, origin = $origin,
+ id = 2, fully qualified name = 'public.branches',
+ comment = 'Table branches');
+ set add table (set id = $mainset, origin = $origin,
+ id = 3, fully qualified name = 'public.tellers',
+ comment = 'Table tellers');
+ set add table (set id = $mainset, origin = $origin,
+ id = 4, fully qualified name = 'public.history',
+ key = serial, comment = 'Table accounts');
+} on error {
+ exit 1;
+}
+_EOF_
+]]></programlisting>
+
+<para>
+ Le script peut être utilisé en suite pour boucler sur la liste des
+ tables :
+</para>
+
+<programlisting><![CDATA[
+# Basic configuration
+origin=1
+subscriber=2
+mainset=1
+# List of tables to replicate
+TABLES="accounts branches tellers history"
+ADDTABLES=""
+tnum=1
+for table in `echo $TABLES`; do
+ ADDTABLES="$ADDTABLES
+ set add table ($set id = $mainset, origin = $origin,
+ id = $tnum, fully qualified name = 'public.$table',
+ comment = 'Table $tname');
+"
+ let "tnum=tnum+1"
+done
+slonik <<_EOF_
+$PREAMBULE
+try {
+ table add key (node id = $origin, fully qualified name =
+ 'public.history');
+} on error {
+ exit 1;
+}
+try {
+ create set (id = $mainset, origin = $origin,
+ comment = 'Set $mainset - pgbench tables');
+$ADDTABLES
+} on error {
+ exit 1;
+}
+_EOF_
+]]></programlisting>
+
+<para>
+ Ce n'est peut-être pas nécessaire si vous n'avez que quatre tables mais cette
+ méthode évite de recopier de longues listes de configuration à la main et
+ préviendra les erreurs sur les grands ensembles que vous rencontrerez dans
+ la <quote>vraie vie</quote>.
+</para>
+
+<para>
+ Vous pouvez créer des scripts encore plus sophistiqués si votre langage de
+ script possède :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ des structures de type <quote>Record</quote> qui permettent d'assigner
+ des objets en parallèle ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ des fonctions, procédure ou des routines qui permettent d'implanter des
+ fonctionnalités une seule fois, puis de les appeler à divers endroits
+ de votre script.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Un mécanisme d'<quote>import de module</quote> afin de partager de
+ fonctionnalités commune entre plusieurs scripts.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Si vous devez utiliser <ulink
+ url="http://www.gnu.org/software/bash/bash.html">Bash</ulink>, <ulink
+ url="http://www.zsh.org/">zsh</ulink> ou <ulink
+ url="http://www.kornshell.com/">Korn shell</ulink>, tous ces shells possèdent
+ des extensions qui gèrent correctement les structures de données
+ sophistiquées et les modules. Sur linux, Bash est très répandu ; sur les
+ systèmes <trademark>UNIX</trademark> commerciaux, Korn est le standard alors
+ que sur BSD, les shells <quote>sophistiqués</quote> sont en option.
+</para>
+
+<para>
+ N'oubliez pas de regarder du côté des des autres langages de script, parmi
+ lesquels Perl est le plus évident, puisqu'il est largement répandu sur Linux,
+ <trademark>UNIX</trademark> et BSD.
+</para>
+
+</sect1>
+
+<sect1 id="noslonik">
+<title>Ne pas utiliser Slonik - les fonctions &slony1; de bas niveau</title>
+<indexterm><primary>fonctions &slony1; de bas niveau</primary></indexterm>
+
+<para>
+ Il est parfois nécessaire d'utiliser directement les procédures stockées
+ qui composent les différentes parties de &slony1;. Slonik n'est pas
+ <quote>magique</quote> ; il est courant qu'une commande Slonik se
+ contente de décider le nœud qui va recevoir la commande et lui
+ envoie une requête SQL qui contient une seule procédure stockée &slony1;.
+</para>
+
+<para>
+ Les développeurs de &slony1; espèrent que quelqu'un développera des outils
+ graphiques qui constitueront une alternative à Slonik ; il serait alors
+ utile d'envoyer les ordres de configuration directement via les procédures
+ stockées. Si vous comptez vous lancer dans ce projet, il est conseillé
+ d'examiner comment les procédures stockées sont utilisées dans le fichier
+ <filename>slonik.c</filename> puisqu'il s'agit de l'utilisation la plus
+ correcte de ces fonctions.
+</para>
+
+<para>
+ Lorsque qu'on corrige des problèmes sur un cluster &slony1;
+ <quote>endommagé</quote>, il est parfois utile d'utiliser les procédures
+ stockées. C'est particulièrement efficace lorsque la configuration de la table
+ <xref linkend="table.sl-listen"/> est corrompue et que les événements ne se
+ propagent plus correctement. La méthode la <quote>plus simple</quote> pour
+ réparer cela est la suivante :
+</para>
+
+<para>
+
+<command>SELECT _slonycluster.droplisten(li_origin,li_provider,li_receiver)
+FROM _slonycluster.sl_listen;</command>
+
+</para>
+
+<para>
+
+<command>SELECT _slonycluster.storelisten(pa_server, pa_server, pa_client)
+FROM _slonycluster.sl_path;</command>
+
+</para>
+
+<para>
+ Le résultat de ces requêtes est la regénération et la
+ <emphasis>propagation</emphasis> des voies d'écoute. En lançant à la main la
+ fonction <function> _slonycluster.storelisten()</function>, on déclenche des
+ évènements <command>STORE_LISTEN</command> qui provoquent l'envoi des voies
+ d'écoute sur les autres nœuds du cluster.
+</para>
+
+<para>
+ En cas de problème <emphasis>local</emphasis> sur un nœud, si vous ne
+ souhaitez pas propager les corrections (ce qui est assez rare, on cherche en
+ général à réparer <emphasis>l'ensemble</emphasis> du cluster), la requête
+ est la suivante :
+</para>
+
+<para><command>SELECT slonycluster.droplisten_int(li_origin,li_provider,li_receiver)
+FROM _slonycluster.sl_listen;</command></para>
+
+<para><command>SELECT _slonycluster.storelisten_int(pa_server, pa_server, pa_client)
+FROM_slonycluster.sl_path;</command></para>
+
+<para>
+ Si vous souhaitez ajouter le support de &slony1; dans d'autres outils
+ (<emphasis>par exemple :</emphasis> ajouter la réplication dans <ulink
+ url="http://www.pgadmin.org/"><productname>pgAdmin III</productname></ulink>),
+ vous devez savoir clairement quelles fonctions il faut appeler. Le
+ <quote>protocole</quote> normal est le suivant :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ La fonction <quote>principale</quote> (<emphasis>par exemple</emphasis>
+ celle sans le suffixe <command>_int</command>) est appelée sur un
+ nœud <quote>adéquat</quote> du cluster &slony1;.
+ </para>
+
+ <para>
+ Dans la plupart des cas, la fonction peut être appelée sur n'importe
+ quel nœud, et elle propage correctement les commandes aux autres
+ nœuds. C'est vrai pour <xref
+ linkend="function.storelisten-integer-integer-integer"/>, par exemple.
+ </para>
+
+ <para>
+ Dans d'autres cas, la fonction doit être lancée depuis un nœud
+ particulier car c'est le seul endroit où les données sont valides.
+ Par exemple, <xref
+ linkend="function.subscribeset-integer-integer-integer-boolean"/> doit
+ être appelée sur le nœud récepteur.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si la fonction <quote>principale</quote> réussit, alors le changement de
+ configuration est effectué sur le nœud local et un événement est
+ créé avec <xref linkend="function.createevent-name-text"/> pour que le
+ changement de configuration soit propagé à tous les autres nœuds
+ du cluster &slony1;.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Troisièmement, la version <command>_int</command> de la fonction doit
+ être lancée.
+ </para>
+
+ <para>
+ Dans certains cas, lorsque les fonctions sont idempotentes, le nœud
+ sur lequel la fonction <quote>principale</quote> est exécutée peut traiter
+ la version <command>_int</command> très tôt.
+ </para>
+
+ <para>
+ Au moment où l'événement se propage, les nœuds lancent la version
+ <command>_int</command>, en espérant que tout se passe bien.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect1>
More information about the Trad
mailing list