[Trad] [svn:pgfr] r1239 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Mer 11 Fév 23:07:11 CET 2009
Author: gleu
Date: 2009-02-11 23:07:11 +0100 (Wed, 11 Feb 2009)
New Revision: 1239
Modified:
traduc/trunk/slony/addthings.xml
traduc/trunk/slony/failover.xml
traduc/trunk/slony/firstdb.xml
traduc/trunk/slony/logshipping.xml
traduc/trunk/slony/slon.xml
Log:
Relecture, ?\195?\169tape 5.
Modified: traduc/trunk/slony/addthings.xml
===================================================================
--- traduc/trunk/slony/addthings.xml 2009-02-10 22:41:58 UTC (rev 1238)
+++ traduc/trunk/slony/addthings.xml 2009-02-11 22:07:11 UTC (rev 1239)
@@ -6,417 +6,603 @@
<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>
+ 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
-une <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>
+ 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="slonik"/> <xref linkend="stmtsetaddtable"/>
-ou <xref linkend="stmtsetaddsequence"/> 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. Un 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>
+ 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 noeuds ayant ces
-événements en attente.
+<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>
-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 noeuds
-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> Notez que si vous ajoutez des noeuds, vous devez également ajouter
-les déclarations <xref linkend="stmtstorepath"/> pour indiquer comment
-les noeuds 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>
+ 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>Il est conseillé d'être très prudent lorsque l'on ajoute des noeuds 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. Si 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>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>
-<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>
-<sect2><title> Ajouter une table dans le cluster de réplication </title>
+<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>
-<indexterm><primary> ajouter une table dans le cluster de réplication </primary></indexterm>
+<para>
+ En contrepartie, vous devez procéder de la manière suivante :
+</para>
-<para> &slony1; ne vous permet pas d'ajouter une table dans un ensemble de
-qui est déjà en cours de réplication. En principe, c'est certainement
-<emphasis>possible</emphasis>; mais cela implique 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 noeud. </para>
+ <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é ce 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 noeuds, 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>
+ 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> A contrario, vous pouvez ajouter la table via
-<application>psql</application> sur chaque noeud.
+ <para>
+ À contrario, vous pouvez ajouter la table via <application>psql</application>
+ sur chaque nœud.
+ </para>
+ </listitem>
-</para> </listitem>
+ <listitem>
+ <para>
+ Créer un nouvel ensemble de réplication avec <xref linkend="stmtcreateset"/>.
+ </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>
+ 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"/>. Si il existe plusieurs noeuds, vous devez
-utiliser <xref linkend="stmtsubscribeset"/> une fois pour chaque noeud
-que vous voulez abonner. </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 :
+ <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);
+ <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>
+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 soit identiques
-à ceux de l'ancien ensemble, vous pouvez fusionner le nouveau et l'ancien
-avec la commande <xref
-linkend="stmtmergeset"/> </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>
+<sect2>
+<title>Comment ajouter une colonne dans une table répliquée</title>
+<indexterm><primary>ajouter des colonnes dans une table</primary></indexterm>
-<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> 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
-au 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>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 noeuds
-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> Ainsi, la méthode pour consiste à construire un script SQL
-composé des changements DDL et de le soumettre à tous les noeuds
-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> 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> <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> Tapez la commande <command>slonik_execute_script -h</command> pour
-plus d'information; notez que ce script utilise <xref linkend="stmtddlscript"/>.
+<para>
+ Il y a de nombreux <quote>points délicats</quote> à noter...
</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 de opérateur de contrôle de transaction supplémentaire
-implique que des parties des ordres DDL seront <quote>committés</quote>
-en dehors du contrôle de &slony1; </para></listitem>
+ <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>
+ <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 quotes'</command>
-dans le script, car cela l'empêchait d'être stocké et transmis correctement
-. A partir de la version 1.2, les quotes sont correctement prises en compte. </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 un requête unique,
-dont le plan d'exécution est basé sur l'état de la base de donnée
-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>
+ <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>
-</itemizedlist>
</sect2>
-<sect2><title> Comment supprimer la réplication sur un noeud</title>
+<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>
+ Vous devez supprimer les différents composants &slony1; connectés à la base.
+</para>
-<para> Considérons, un instant, que nous faisons cela pour un noeud.
-Si vous avez de multiples noeuds, vous devrez répéter ces étapes
-autant de fois que nécessaire.</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>
+<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>Triggers de logs / Triggers de blocage de mises à jour
-
-</para></listitem>
-<listitem><para> Le schéma <quote>cluster</quote> contenant les tables &slony1;
-qui indiquent l'état du noeud et diverses procédures stockées
-</para></listitem>
-<listitem><para> Le processus &lslon; qui gère le noeud </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>
+ <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>
+<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> Vous pouvez utiliser la commande Slonik <xref linkend="stmtdropnode"/>
-pour supprimer un noeud du cluster. Ceci provoquera la suppression
-des triggers et tout ce qui se trouve dans schéma cluster.
-Le processus <xref linkend="slon"/> sera automatiquement mourir.</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>
-<listitem><para> Dans le cas d'un noeud en échec ( lorsque vous avez utilisé
-la commande <xref linkend="stmtfailover"/> pour basculer sur un autre noeud
-), 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>
-<para> Si le noeud 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 noeud;
-En général, la base ne survive 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 noeud à 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><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>
-<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 noeud dans le cluster de réplication</title>
+<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 noeud flambant neuf et la restauration d'un noeud qu'on supprimé, puis reconstruit
-. Dans les deux cas, vous ajouter un noeud dans le cluster de réplication.
- </para>
+<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 noeud et les DSNs adéquates
-pour le noeuds. 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>
+ Les étapes nécessaires sont...
</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>
+<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>
-<listitem><para> Si le noeud était un noeud en échec, vous devez lancer
-la commande <xref linkend="slonik"/> <xref linkend="stmtdropnode"/>
-afin de vous débarrasser de ses vestiges dans le cluster et de supprimer
-le schéma que &slony1; a créé.
-</para></listitem>
+ <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> Lancer la commande slonik <xref linkend="stmtstorenode"/>
-pour établir le nouveau noeud.
-</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> À cet instant, vous pouvez lancer le démon &lslon; sur le nouveau
-noeud. Il ne connaîtra rien des autres noeuds, donc les logs de ce noeud seront
-particulièrement calmes.
-</para></listitem>
+ <listitem>
+ <para>
+ Lancer la commande <xref linkend="stmtstorenode"/> de slonik pour établir
+ le nouveau nœud.
+ </para>
+ </listitem>
-<listitem><para> Lancer la commande slonik <xref linkend="stmtstorepath"/>
-pour indiquer comment les processus <xref linkend="slon"/> doivent
-communiquer avec le nouveau noeud.
-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, 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> A cet instant, lancer le script
-<command>test_slony_state-dbi.pl</command> est une excellente idée.
-Ce script parcours le cluster le 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 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> Lancer commande slonik
-<xref linkend="stmtsubscribeset"/> pour abonner le noeud à l'ensemble de réplication.
-</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>
+<sect2>
+<title>Comment remanier les abonnements ?</title>
-<para> Par exemple, on souhaite que le noeud 3 reçoivent les données
-en provenance du noeud 1, alors qu'actuellement il reçoit les données du noeud 2. </para>
+<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>
+ 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>
+<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><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>
+<sect2>
+<title>Comment utiliser le <link linkend="logshipping">Log Shipping</link> ?</title>
-<para> La preuve ultime est le fait que les données ajoutées sur l'origine
-soit présentes sur les abonnés. Il suffit <quote>simplement de lancer une
-requête</quote> pour le savoir.</para>
+<para>
+ Cette question est largement débattue dans la section <link
+ linkend="logshipping">Log Shipping</link>...
+</para>
-<para> Cependant, il existe quelques autres méthode pour examiner l'état de la réplication : </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>
+ <listitem>
+ <para>Regarder les logs des processus &lslon;.</para>
-<para> Ils ne vous diront pas grand chose, même à une niveau de debug
-élevé sur le noeud origine; Au niveau 2 de debug, 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
-SYNCs incluent le nombres de tables traitées, ainsi que le nombre
-de tuples insérés, supprimés et mis à jour.</para> </listitem>
+ <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 noeud origine. </para>
+ <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 noeuds abonnés.
-Cette information n'est pertinente que sur un noeud origine.</para> </listitem>
+ <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
-script <command>test_slony_state-dbi.pl</command> qui se trouve dans le répertoire
-<filename>tools</filename>. Ce script parcours le cluster tout entier et pointe les
-anomalies qu'il détecte, ainsi que des informations sur le statut de chaque noeud.
-</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>
+<sect2>
+<title>Comment mettre à jour la version de &slony1; ?</title>
-<para> La réponse se trouve <link linkend="slonyupgrade"> ici </link> </para> </sect2>
+<para>
+ La réponse se trouve <link linkend="slonyupgrade">ici</link>.
+</para>
-<sect2><title> Que se passe-t-il lors d'une bascule d'urgence ?</title>
+</sect2>
-<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>Que se passe-t-il lors d'une bascule d'urgence ?</title>
-<sect2><title> Comment <quote>déplacer le maître</quote> vers un autre noeud ? </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>
-<para> Tout d'abord il faut choisir un noeud qui est connecté à l'ancienne origine
-(sinon il n'est pas évident de conserver les connexions lors du changement). </para>
+</sect2>
-<para> Deuxièmement, vous devez lancer un script &lslonik; avec la commande
-<xref linkend="stmtlockset"/> pour verrouiller l'ensemble de réplication sur
-le noeud 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>
+<sect2>
+<title>Comment <quote>déplacer le maître</quote> vers un autre nœud ?</title>
-<para> Maintenant, lancez la requête &lslonik; <xref linkend="stmtmoveset"/>.
-Il parfaitement raisonnable de soumettre les deux requêtes à l'intérieur
-d'un même script &lslonik;.
+<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>
-Désormais, l'origine est basculée vers le nouveau noeud origine. Si le nouveau noeud a quelques
-événement de retard, il faudra un peu de temps pour que tout se mette en place. </para> </sect2>
+<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>
-<sect2> <title> Comment réaliser <quote>synchronisation complète</quote> sur une table? </title>
+<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>
-<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>committée</quote> pendant
-durée d'un événement <command>SYNC</command> donné sur le noeud origine.
-Si des mises à jour qui ont altérées l'ensemble du contenu d'une
-table sont <quote>committé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>
+</sect2>
-<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 noeud fournisseur.</para>
+<sect2>
+<title>Comment réaliser une <quote>synchronisation complète</quote> sur une table ?</title>
-<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>
+ 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> Si une corruption très grave se produit, la réponse est de retirer la table
-hors de la réplication, puis de créer un nouvel ensemble de réplication et de l'ajouter
-à nouveau. </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>
Modified: traduc/trunk/slony/failover.xml
===================================================================
--- traduc/trunk/slony/failover.xml 2009-02-10 22:41:58 UTC (rev 1238)
+++ traduc/trunk/slony/failover.xml 2009-02-11 22:07:11 UTC (rev 1239)
@@ -5,341 +5,419 @@
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>
+<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>
+<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 ou le noeud origine d'un ensemble de réplication
- tombe en panne, la dernière transaction <quote>committée</quote> sur
- l'origine ne soit pas encore propagée aux abonnés. Les systèmes qui tombent
- en panne souvent soumis à une forte charge; c'est une des corollaires de la
- loi de Murphy. Ainsi le but principal est d'<emphasis>éviter</emphasis> que le serveur principal
- tombe en panne. La meilleur façon d'éviter cela est d'effectuer une
- maintenance fréquente.</para>
+<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
- 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 de fournir des
- méthodes de reprise sur panne, il intègre également la notion de
- transfert d'origine.</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 une système de réplication &slony1; composé de deux noeuds.
- </para>
- </sect2>
+<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><title>Bascule contrôlée</title>
+</sect2>
- <indexterm>
- <primary>bascule contrôlée</primary>
- </indexterm>
+<sect2>
+<title>Bascule contrôlée</title>
+<indexterm><primary>bascule contrôlée</primary></indexterm>
- <para> Imaginons un noeud <quote>origine</quote>, appelé noeud1, avec un
- <quote>abonné</quote> appelé noeud2 (l'esclave). Une application web, placée
- sur un troisième serveur, accède à la base de données sur noeud1.
- 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>
+<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>pg_pool</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> rôle.
- Il y a différentes façon 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>
+<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
- <ulink url="http://www.iana.org/assignments/dns-parameters"> champs DNS </ulink>
- CNAME qui permet à l'application d'utiliser un nom pour référencer le noeud
- qui joue le rôle du noeud <quote>maître</quote>.</para>
+ <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 point et vers le nouveau serveur, de plus il faut probablement relancer
- l'application pour rafraîchir les connexions à la base.</para>
- </listitem>
+ <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>pg_pool</application> ou
- un <quote>gestionnaire de connexion</quote> similaire, alors la reconfiguration
- implique de modifier le paramètre de cet outil, à part cela la procédure est similaire
- à l'exemple DNS/CNAME ci-dessus. </para>
- </listitem>
- </itemizedlist></para>
-
-
-
- <para> Le nécessité de redémarrer l'application qui se connecte à la base dépend
- de la manière dont elle a été conçu 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 un 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 ( le rôle du maître) de l'ensemble de réplication 1
- est transféré sur le noeud 2. En fait elle n'est pas simplement transférée; le noeud1 devient
- un abonné parfaitement synchronisé et actif. En clair, les deux noeuds ont échangé
- leurs rôles respectifs.</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 :
- <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 noeud 2, le serveur web est redémarré et
- reprend son activité normale.</para>
+ <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>
+ 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 noeud 1 et
- effectuer les opérations de maintenance requise. Lorsque le démon <xref
- linkend="slon"/> du noeud 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>
+ 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>
+<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>
+</sect2>
- <indexterm>
- <primary>Bascule suite à une panne du système</primary>
- </indexterm>
+<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.
- C'est cas de figure qui n'a rien de souhaitable, car les transactions
- <quote>committé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>. 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>
+ 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 de détection des pannes du système.
- Abandonner des transactions <quote>committé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, et bien .... ce sont
- <emphasis>vos</emphasis> données, et <emphasis>votre</emphasis> politique
- de bascule d'urgence. </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>
-
+<itemizedlist>
<listitem>
- <para>La commande <xref linkend="slonik"/>
- <programlisting>
- failover (id = 1, backup node = 2);
- </programlisting>
- </para>
+ <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> ordonne au noeud 2 de se considérer comme le propriétaire
- (l'origine) de tous les sets que le noeud 1 possédait. Si il
- existe des noeuds supplémentaire dans le cluster &slony1;
- Tous les noeuds abonnés au noeud 1 sont avertis du changement.
- <application>Slonik</application> va aussi envoyer une requête
- à chaque abonné pour déterminer quel noeud à le plus haut niveau
- de synchronisation (<emphasis>c'est à dire</emphasis> - la dernière
- transaction <quote>committée</quote>) pour chaque ensemble de réplication.
- et la configuration sera changé de façon à ce que le noeud 2 applique
- d'abord ces transactions finales, avant d'autoriser l'accès en écriture
- sur les tables.</para>
-
- <para> De plus, tous les noeuds qui étaient abonnés directement au noeud 1
- considéreront désormais le noeud 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 noeud du cluster ne
- reçoit d'information de la part du noeud 1.</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 noeud 2.</para>
+ <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 noeud abandonné </para>
+ <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 noeud 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 noeud. </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 sera complète et que le noeud 2 accepte
- les opérations d'écriture sur les tables répliquées, il faut supprimer
- toutes informations de configuration rémanentes avec la commande
- <xref linkend="stmtdropnode"/> :
+ <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>
+ <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 noeud 1, il est possible qu'il ne <quote>reste</quote> plus
- rien sur le noeud 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 noeud 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>
-
+ <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>
+</itemizedlist>
- </sect2>
+</sect2>
- <sect2><title> Automatisation de la commande <command> FAIL OVER </command> </title>
+<sect2>
+<title>Automatisation de la commande <command>FAIL OVER</command></title>
+<indexterm><primary>automatisation des bascules d'urgence</primary></indexterm>
- <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>
- <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 noeud en panne est réellement en panne, et vous
- être capable de vous assurer que le noeud en panne ne redémarre pas,
- ce qui entraînerait un conflit entre deux noeuds 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>
- <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 gravieuse, car une fois qu'une est marqué
- comme étant en panne, les autres noeuds <quote>l'oublier</quote>
- et l'ignorer. Le problème se situe plutôt au niveau de
- <emphasis>votre application</emphasis>.
- Supposons que le noeud 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> Lorsqu'une bascule d'urgence est effectuée, il faut un
- mécanisme pour dégager de force le noeud 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>
- <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>
- <para> Si l'on en fait attention, le serveur peut réapparaître dans le
- système de réplication lorsque les administrateurs le rallume. </para>
+ <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>
- </listitem>
-
- <listitem><para> Modifier de règles de pare-feu ou d'autres configuration
- 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 l'application,
- tout en conservant les adresses <quote>administratives</quote> afin
- que le serveur reste accessible par les administrateurs systèmes.
- </para> </listitem>
-
+ <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>
+</para>
- <sect2 id="rebuildnode1"><title>Après la bascule d'urgence, reconfiguration
- de l'ancienne origine</title>
+</sect2>
- <indexterm><primary>reconstruction après une bascule d'urgence</primary></indexterm>
+<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 noeud en panne dépend beaucoup de la nature de la catastrophe
- qui a conduit à la bascule d'urgence vers un autre noeud. Si le noeud
- 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 noeud a été abandonné
- à cause d'une coupure réseau, qui n'a pas perturbé le fonctionnement normal
- du noeud <quote>fournisseur</quote>. Toutefois une fois que les communications
- sont restaurées, le fait est que le commande <command>FAIL OVER</command>
- rend obligatoire l'abandon du noeud qui était en panne.</para>
+<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
- noeud 1 seront rapidement et de plus en plus désynchronisées.
- par rapport aux autres noeuds. Elles doivent être considérées comme
- corrompues. Ainsi le seul moyen pour que le noeud 1 retourne dans
- le cluster de réplication et qu'il redevienne le noeud 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>
+ 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'importante mises à jour ( d'un point de
- vue <emphasis>commercial</emphasis> ) ont pu être
- <quote>committée</quote> sur le système en panne.
- Vous souhaiterez probablement analyser les dernières transactions que
- le noeud 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>
+<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
- noeud <quote>tombe en panne</quote> à cause d'une coupure réseau persistante,
- par opposition aux pannes du système de stockage. Dans de tel scénarios,
- le noeud <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 noeuds,
- il <quote>crie en silence</quote>. </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 noeud peut réapparaître
- et conformément <emphasis>sa</emphasis> configuration, il va communiquer avec les
- autres noeuds du cluster &slony1;. </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 noeud. Les autres noeud du cluster ne sont pas du tout perturbés;
- ils savent que ce noeud est <quote>mort</quote>, et qu'ils doivent
- l'ignorer. Mais il est impossible de savoir cela en regardent le noeud
- qui a était <quote>en panne</quote>.
+ <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 quels bases de données doivent être utilisées. 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>
+ 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>
+</warning>
- <para> Si la base de données est très volumineuse, la construction du noeud 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>
+<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>
+</sect2>
</sect1>
Modified: traduc/trunk/slony/firstdb.xml
===================================================================
--- traduc/trunk/slony/firstdb.xml 2009-02-10 22:41:58 UTC (rev 1238)
+++ traduc/trunk/slony/firstdb.xml 2009-02-11 22:07:11 UTC (rev 1239)
@@ -4,237 +4,282 @@
par $Author$
révision $Revision$ -->
-<sect1 id="firstdb"><title>Répliquer votre première base de données</title>
+<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>
-<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>Dans cet exemple, nous allons répliquer une base de donnée
- <application>pgbench</application> neuve. Les mécanismes de réplications
- d'une base existante sont abordé 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 une 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>
+ 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ée sur les triggers, ce qui permet
- répliquer des bases de données ( ou des parties de celles-ci ) hébergées par le
- même postmaster.</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ées 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>
+<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; :
-<listitem><para> Vous avez la ligne <option>tcpip_socket=true</option> dans votre
-<filename>postgresql.conf</filename> et </para></listitem>
+ <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 activer les accès à votre cluster via
-<filename>pg_hba.conf</filename></para></listitem>
+ <listitem>
+ <para>
+ Vous avez activé les accès à votre cluster via
+ <filename>pg_hba.conf</filename>.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
-</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> 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 :
-<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>
+ <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>
+ 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>
+ <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>
+ <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>
-<sect2><title>Créer l'utilisateur <application>pgbench</application></title>
+<para>
+ <command>createuser -A -D $PGBENCHUSER</command>
+</para>
-<para><command>
-createuser -A -D $PGBENCHUSER
-</command>
-</para>
</sect2>
+
<sect2><title>Préparer les bases</title>
-<programlisting>
-createdb -O $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME
+<programlisting>createdb -O $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME
createdb -O $PGBENCHUSER -h $SLAVEHOST $SLAVEDBNAME
-pgbench -i -s 1 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME
-</programlisting>
+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érieurs de &slony1;, un 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és fut supprimée dans la version 2 &slony1;. Il est désormais
-<emphasis>nécessaires</emphasis> d'avoir une ensemble éligible en tant que
- clé primaire. </para>
+<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>
+<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
+<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>
+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>.
+<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>
+ <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 à lui, ainsi nous devons importer
- ces données. Nous réalisons cette opération avec <application>pg_dump</application>.
+<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>
+ <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 tache de premier plan
- dans une fenêtre de terminal séparée, vous pouvez l'arrêter et la 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>
+ 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 :
+<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>
+ <programlisting>pgbench -s 1 -c 5 -t 1000 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME</programlisting>
</para>
-<para>Ceci lancera <application>pgbench</application> avec 5 clients concurrents,
+<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>
+</para>
-<sect2><title>Configurer la base de donnée pour la réplication.</title>
+</sect2>
-<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 noeuds maître et esclaves.</para>
+<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>
-<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 :
+ 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:
+<programlisting># Initialisation du cluster:
$ slonik_init_cluster | slonik
-# Démarrage de slon (ici 1 et 2 sont les numéros de noeuds)
+# 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 noeud (1= n° d'ensemble, 2= n° de noeud)
-$ slonik_subscribe_set 1 2 | slonik
-</programlisting>
+# 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>
+<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>
+<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>
+ 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>
+<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éfintion de l'espace de nom du système de réplication
- # dans notre exemple il s'agit de exemple_slony
+ # 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 dans la
- # C-API
+ # 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 schema _$CLUSTERNAME contenant tous les objets spécifiques du système
- # de réplication
+ # 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
+ # 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.
@@ -243,8 +288,8 @@
#--
# 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éée un ensemble contenant 4 tables pgbench.
+ # 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');
@@ -264,39 +309,45 @@
_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>
+ L'application <application>pgbench</application> est-elle toujours
+ exécutée ? Si ce n'est pas le cas, redémarrez-la.
</para>
-<para>A ce moment, nous avons 2 bases de données qui sont complètement préparées.
- 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>
+ À 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 :
+<para>
+ Sur $MASTERHOST, la commande pour démarrer le moteur de réplication est :
-<programlisting>
-slon $CLUSTERNAME "dbname=$MASTERDBNAME user=$REPLICATIONUSER host=$MASTERHOST"
-</programlisting>
+ <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 noeud 2 (l'esclave)
-<programlisting>
-slon $CLUSTERNAME "dbname=$SLAVEDBNAME user=$REPLICATIONUSER host=$SLAVEHOST"
-</programlisting>
+<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é sur
- à 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 sommes toujours
- pas répliquées. L'activité que vous constatez est la synchronisation de la
- configuration du cluster entre les 2 processus <xref linkend="slon"/>.
- </para>
-<para>Pour démarrer la réplication des 4 tables <application>pgbench</application>
- (l'ensemble 1) depuis le maître (le noeud 1) vers l'esclave (le noeud 2),
- lancez le script suivant :
+<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>
-<programlisting><![CDATA[
+<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_
# ----
@@ -306,7 +357,7 @@
# ----
# Les paramètres conninfo sont utilisés par le programme slonik
- # pour se connecter aux noeuds. Ce sont donc les arguments
+ # 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).
# ----
@@ -317,33 +368,40 @@
# Le noeud 2 s'abonne à l'ensemble 1
# ----
subscribe set ( id = 1, provider = 1, receiver = 2, forward = no);
-_EOF_
-]]></programlisting>
+_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 4 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ée, le démon de réplication sur le noeud
- <envar>$SLAVEHOST</envar> commencera à se synchroniser en appliquant les journaux
- de réplications qui auront été accumulés.
- Cela se fera par petit à petit, par tranches de 10 secondes de travail applicatifs.
- Selon les performances des 2 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>
+ 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 un 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>
+ 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
- compares. Assurez-vous que le test <application>pgbench</application> est terminé,
- qu'il n'y pas d'autres mises à jour en cours sur le noeud origine, et que les sessions
- slons se sont synchronisées.</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
@@ -380,11 +438,19 @@
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>
+ 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 retourne <command>FAILED</command>, merci de contacter les développeurs sur
-<ulink url="http://slony.info/">http://slony.info/</ulink></para></sect3>
+<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>
Modified: traduc/trunk/slony/logshipping.xml
===================================================================
--- traduc/trunk/slony/logshipping.xml 2009-02-10 22:41:58 UTC (rev 1238)
+++ traduc/trunk/slony/logshipping.xml 2009-02-11 22:07:11 UTC (rev 1239)
@@ -8,345 +8,507 @@
<title>Log Shipping</title>
<indexterm><primary>log shipping</primary></indexterm>
-<para> Une des nouvelles fonctionnalités de la version 1.1, qui
- ne fut réellement stable qu'à partir de la version 1.2.11,
- est la possibilité de regrouper les mises à jour dans des fichiers
- de logs qui sont stockés dans un répertoire d'attente.
- </para>
+<para>
+ 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 log peuvent alors être transférés selon la
- méthode de votre choix vers le <quote>serveur esclave</quote>,
- que ce soit via FTP, rsync, ou même avec une <quote>clé USB</quote>
- d' 1GB transportée par avion.</para>
+<para>
+ 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 sympas à faire avec un tel flux de donnée,
- en particulier :
-<itemizedlist>
+<para>
+ Il y a plein de choses intéressantes à faire avec un tel flux de données,
+ en particulier :
- <listitem><para> Répliquer des noeuds qui
- <emphasis>ne peuvent pas</emphasis> être securisés;</para></listitem>
+ <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 ou il n'est pas possible
- d'établir des communications bidirectionnelles;</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>
+ Utiliser une nouvelle forme de <acronym>PITR</acronym> (Point In Time
+ Recovery) qui filtre les transactions composées uniquement de lectures
+ et celles qui mettent à jour des tables qui ne sont pas
+ intéressantes ;
+ </para>
+ </listitem>
- <listitem><para> En cas de désastre, vous pouvez regarder à l'intérieur
- des logs pour voir le détail des requêtes;</para>
+ <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 noeud répliqué;
- </para></listitem>
+ <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 un méthode très subtile pour charger
- des données en vue de tests;
- </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>
+ Nous avons un système <quote>escrow</quote> qui serait incroyablement
+ moins cher avec du log shipping ;
+ </para>
+ </listitem>
- <listitem><para> Vous pouvez appliquer des triggers sur un
- <quote>noeud déconnecté</quote> pour effectuer des traitements
- supplémentaires sur les données.</para>
+ <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 that implémentent les techniques décrites dans
- <citation>Developing Time-Oriented Database Applications in SQL
- </citation> de <ulink url="http://www.cs.arizona.edu/people/rts/">
- Richard T. Snodgrass</ulink>.</para></listitem>
+ <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>
-</itemizedlist></para>
-
<qandaset>
-<qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ Où sont générés les <quote>fichiers de journalisation</quote> d'un
+ ensemble de réplication donné ?
+ </para>
+ </question>
-<question> <para> Où sont générés les <quote>fichiers de log</quote> d'un
- ensemble de réplication donné ?</para>
-</question>
+ <answer>
+ <para>
+ Chaque nœud abonné <link linkend="slon">slon</link> peut les
+ générer en ajoutant l'option <option>-a</option>.
+ </para>
-<answer> <para> Chaque noeud abonné <link linkend="slon"> slon </link>
- peut les générer en ajoutant l'option <option>-a</option>.</para>
+ <note>
+ <para>
+ Notez que cela implique que, pour utiliser le log shipping, vous
+ devez avoir au moins un nœud abonné.
+ </para>
+ </note>
+ </answer>
+ </qandaentry>
-<note><para> Notez que cela implique que pour utiliser le log
-shipping, vous devez avoir au moins un noeud abonné. </para></note>
-</answer>
+ <qandaentry>
+ <question>
+ <para>
+ Que se passe-t-il lors d'un <xref linkend="stmtfailover"/>/<xref
+ linkend="stmtmoveset"/> ?
+ </para>
+ </question>
-</qandaentry>
+ <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>
-<qandaentry> <question> <para> Que se passe-t-il lors d'un <xref
-linkend="stmtfailover"/>/ <xref linkend="stmtmoveset"/>
- se déclenche ?</para></question>
+ <answer>
+ <warning>
+ <para>
+ Si le nœud d'archivage devient l'origine, il continuera à
+ produire des fichiers de journalisation.
+ </para>
+ </warning>
+ </answer>
+ </qandaentry>
-<answer><para> Rien de spécial. Tant que le noeud d'archivage rester un abonné
- il continue à produire des logs.</para></answer>
+ <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> <warning> <para>Si le noeud d'archivage devient l'origine, il
- continuera à produire des logs.</para> </warning></answer>
-</qandaentry>
+ <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> Que se passe-t-il lorsqu'il n'y a plus assez d'espace
- pour les fichiers de logs ? </para></question>
+ <qandaentry>
+ <question>
+ <para>
+ Comment réaliser un abonnement ?
+ </para>
+ </question>
-<answer><para> Le noeud n'accepte plus les événements <command>SYNC</command>s
-jusqu'à ce que le problème soit réglé. La base de donnée qui est dupliquée
-tombera également en panne. </para></answer>
-</qandaentry>
+ <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>
-<qandaentry>
-<question> <para> Comment réaliser un abonnement ? </para></question>
+ <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>
-<answer><para> Le script dans <filename>tools</filename> nommé
-<application>slony1_dump.sh</application> est un script shell qui
-exporte l'état <quote>actuel</quote> du noeud abonné.</para>
+ <qandaentry>
+ <question>
+ <para>
+ Quelles sont les limitations du log shipping ?
+ </para>
+ </question>
-<para> Vous devez lancer le <application><link linkend="slon"> slon
-</link></application> pour le noeud abonné avec log shipping activé.
-À tout moment, vous pouvez lancer la commande
-<application>slony1_dump.sh</application>, qui va récupérer l'état
-de l'abonné sous la forme d'événements <command>SYNC</command>.
-Une fois que l'export est complet, tous les logs <command>SYNC</command>
-produits à partir du moment où l'export a <emphasis>démarré</emphasis>
-seront ajoutés à l'export afin d'obtenir un <quote>noeud abonné
- au log shipping</quote>.
-</para></answer>
-</qandaentry>
+ <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>
-<qandaentry> <question><para> Quelles sont les limitations du log
-shipping ? </para>
-</question>
+ <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> Dans la version initiale, il y a beaucoup de limitations.
- Heureusement au fur et à mesure des nouvelles versions, certaines de ces
- limitations ont été corrigées ou supprimées. </para> </answer>
+ <answer>
+ <para>
+ 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> La fonctionnalité du log shipping revient à
-<quote>sniffer</quote> les données appliquées sur un noeud abonné
-. En conséquence, vous devez avoir au moins un noeud
- <quote>standard</quote>; vous ne pouvez pas avoir un cluster composé
- seulement d'une origine et d'un ensemble de <quote>noeuds de log shipping
- </quote>. </para></answer>
+ <answer>
+ <para>
+ 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>
-<answer><para> Le <quote>noeud de log shipping</quote> traque
- la totalité du trafic allant vers un abonné. Vous pouvez
- séparer les choses lorsqu'il y a de multiple ensembles de
- réplication. </para></answer>
+ <para>
+ Une bonne partie des types événements <emphasis>sont</emphasis> gérés
+ afin que le log shipping puissent les traiter :
-<answer><para> Actuellement le <quote>noeud de log shipping </quote>
- traque uniquement les événements <command>SYNC</command>.
- Cela devrait être suffisant pour gérer <emphasis>certains</emphasis>
- changements de la configuration du cluster, mais pas tous.
- </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Bien évidemment, les événements <command>SYNC </command> sont
+ gérés.
+ </para>
+ </listitem>
-<para> Un bonne partie des types événements <emphasis> sont </emphasis>
- gérés afin que le log shipping puissent les traités :
+ <listitem>
+ <para>
+ Les <command>DDL_SCRIPT</command> sont gérés.
+ </para>
+ </listitem>
-<itemizedlist>
+ <listitem>
+ <para>
+ <command>UNSUBSCRIBE_SET</command>
+ </para>
-<listitem><para>Bien évidemment, les événements <command>SYNC </command> sont gérés;
- </para></listitem>
+ <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>
-<listitem><para>Les <command>DDL_SCRIPT</command> sont gérés.</para></listitem>
+ <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> UNSUBSCRIBE_SET </command></para>
+ <listitem>
+ <para>
+ <command>SUBSCRIBE_SET</command>
+ </para>
-<para> Cet événement, tout comme <command>SUBSCRIBE_SET</command> n'est pas
- géré par le noeud de log shipping. Mais cette commande, par définition,
- implique que les événements <command>SYNC</command> ne
- contiennent plus de mises à jour pour l'ensemble de réplication;
- </para>
+ <para>
+ 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> De la même façon, <command>SET_DROP_TABLE</command>,
-<command>SET_DROP_SEQUENCE</command>,
-<command>SET_MOVE_TABLE</command>,
-<command>SET_MOVE_SEQUENCE</command> <command>DROP_SET</command>,
-<command>MERGE_SET</command>, seront géré de manière <quote>appropriée
-</quote>;</para></listitem>
+ <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>
-<listitem><para><command> SUBSCRIBE_SET </command></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> Malheureusement, des choses <quote>étranges</quote> lorsqu'on
- gère cette commande... Quand un <command>SUBSCRIBE_SET</command>
- se produit, cela déclenche un évènement nommé
- <command>ENABLE_SUBSCRIPTION</command>
- qui est levé et traiter uniquement sur le noeud abonné;</para>
+ <para>
+ 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>
-<para> <command> SUBSCRIBE_SET </command> est vraiment un événement
- très simple, il se contente de <emphasis>déclarer</emphasis>
- qu'un noeud s'abonne à un ensemble donné via un fournisseur donné.
- <emphasis>Il ne copie pas les données !</emphasis> </para>
+ <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>
-<para> Le coeur du travail de souscription est réalisé par
-<command>ENABLE_SUBSCRIPTION</command>, qui est un événement
-déclenché sur le noeud local, et non pas dans la même séquence
-que les autres événements en provenance des autres noeuds ( notament
-le fournisseur de données ). </para>
+ <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>
-<para> Avec la modifications du traitement des logs intervenus dans la version 1.2.11,
-ceci ne présente plus de problèmes pour l'utilisateur.</para>
+ <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>
-</listitem>
-
-<listitem><para> Les différents événements impliqués dans la configuration d'un
- noeud sont inutiles dans le cadre du log shipping :
-
-<command>STORE_NODE</command>,
-<command>ENABLE_NODE</command>,
-<command>DROP_NODE</command>,
-<command>STORE_PATH</command>,
-<command>DROP_PATH</command>,
-<command>STORE_LISTEN</command>,
-<command>DROP_LISTEN</command></para></listitem>
-
-<listitem><para> Les événements impliqués dans la configuration
- des ensembles de réplication sont également inutiles :
-
-<command>STORE_SET</command>,
-<command>SET_ADD_TABLE</command>,
-<command>SET_ADD_SEQUENCE</command>,
-<command>STORE_TRIGGER</command>,
-<command>DROP_TRIGGER</command>,
-<command>TABLE_ADD_KEY</command>
-</para></listitem>
-
-</itemizedlist>
-</para>
-</answer>
-
-<answer><para> Il serait pratique de transformer un noeud de <quote>log
-shipping</quote> est un noeud &slony1; complètement fonctionnel sur
-lequel on pourrait basculer. Cela serait utile
-(par exemple) pour un cluster de 6 noeuds; cela permettrait de
-commencer par créer noeud abonné puis d'utiliser le log shipping
-pour construire les 4 autres noeuds en parallèle.
-</para>
-
-<para> Cette utilisation n'est pas possible, mais on peut ajouter
- la configuration &slony1; dans un noeud, et le promouvoir
- en tant que nouveau noeud.
- Encore une fois, c'est une simple question de programmation
- (mais ça n'est pas forcément si simple)... </para></answer>
-</qandaentry>
+ <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>
+<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>
+<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>
-<listitem><para> Vous ne <emphasis>devez</emphasis> pas appliquer aveuglément
- les fichiers <command>SYNC</command> car on en peut pas prendre un
- fichier <command>SYNC</command> au hasard.
- Si ce n'est pas un fichier approprié, alors la
- commande <function> setsyncTracking_offline() </function>
- échouera et votre session <application> psql</application>
- recevra la commande <command> ABORT</command>, puis recherchera
- dans le fichier <command>SYNC</command> à la recherche d'un
- <command>COMMIT</command> ou d'un <command>ROLLBACK</command> afin
- de continuer vers la prochaine transaction.</para>
+ <para>
+ Mais nous <emphasis>savons</emphasis> que la totalité du contenu du
+ fichier va échouer ! Il est futile de continuer à analyser
+ le reste du fichier.
+ </para>
-<para> 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 :
-<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>
-<itemizedlist>
+ <listitem>
+ <para>
+ Essayez de l'appliquer jusque là.
+ </para>
+ </listitem>
-<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>
+ 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> Essayez de l'appliquer jusque là.</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>
-<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>
+ <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> :
-<listitem><para> Si l'appel à <function> setsyncTracking_offline()
-</function> fonctionne, alors vous avez trouver le bon fichier de
-<command>SYNC</command> et vous pouvez l'appliquer. Vous devrez
-probablement faire un <command>ROLLBACK</command> sur la transaction,
-puis utiliser <application>psql</application> pour appliquer
-la totalité des mises à jours contenues dans le fichier.
-</para></listitem>
-
-</itemizedlist></para>
-
-<para> Afin de faciliter la récupération des premières lignes
- des fichiers sync, le format a été conçu pour qu'une ligne
- de pointillée indique la fin de <quote>l'en-tête </quote> :
-
-<programlisting>
--- Slony-I log shipping archive
+ <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>
+ </programlisting>
+ </para>
+ </listitem>
-
-<listitem><para> Notez que l'en-tête inclut le timestamp qui témoigne de la
- date de l'événement SYNC.
-<programlisting>
--- Slony-I log shipping archive
+ <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>
+-- end of log archiving header</programlisting>
+ </para>
-<para> Ce timestamp représente la date où le <command>SYNC</command>
- a été déclenché sur le noeud d'origine.</para>
+ <para>
+ 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>
+ La valeur est stockée dans la table de configuration sl_setsync_offline.
+ </para>
-<para> Si vous construisez une base dynamique, cela représente probablement
- le moment ou voudrez appliquer toute les données d'une tansaction de
- de log shipping. </para>
-</listitem>
+ <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'information sur
- comment l'activité du noeud est enregistré dans
- <xref linkend="logshiplog"/>. </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 logs, car
- leu règle de nommage est devenu plus compréhensible.</para>
+<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>
-<listitem><para> Les traces, sur le noeud de log shipping, qui
- indiquent quel est quel est le log le plus récemment
- traité, sont stockées dans la table <envar>sl_archive_tracking</envar>. </para>
+ <para>
+ Ainsi, vous pouvez prédire l'identifiant du prochain fichier de
+ journalisation en incrémentant le dernier identifiant de cette table.
+ </para>
+ </listitem>
-<para> Ainsi, vous pouvez prédire l'identifiant du prochain
- fichier de log en incrémentant le dernier identifiant de cette
- table.</para>
-</listitem>
+ <listitem>
+ <para>
+ Il existe néanmoins des variations dans le nommage des fichiers, en
+ fonction du nombre de 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>
-<listitem><para> Il existe néanmoins des variations dans le
- nommage des fichiers, en fonction du nombre de noeuds
- qui composent le cluster. Tous les noeuds produisent
- régulièrement des événements <command>SYNC</command>,
- même si ils ne sont pas le noeud origine, et le système
- de log shipping génère des logs pour ces événements. </para>
+ <para>
+ En conséquence, lorsqu'on cherche le fichier de journalisation suivant,
+ il est nécessaire de chercher de la manière suivante :
-<para> En conséquence, lorsque l'on cherche le fichier de log suivant,
- il est nécessaire de chercher de manière suivante :
-
-<programlisting>
-ARCHIVEDIR=/var/spool/slony/archivelogs/node4
+ <programlisting>ARCHIVEDIR=/var/spool/slony/archivelogs/node4
SLONYCLUSTER=mon_cluster
PGDATABASE=logshipdb
PGHOST=logshiphost
@@ -355,125 +517,188 @@
filespec=`printf "slony1_log_*_%20d.sql"
for file in `find $ARCHIVEDIR -name "${filespec}"; do
psql -d ${PGDATABASE} -h ${PGHOST} -f ${file}
-done
-</programlisting>
-</para>
-</listitem>
-
-<listitem><para> </para> </listitem>
+done</programlisting>
+ </para>
+ </listitem>
</itemizedlist>
</sect2>
-<sect2><title> <application> find-triggers-to-deactivate.sh
-</application> </title>
+<sect2>
+<title><application>find-triggers-to-deactivate.sh</application></title>
+<indexterm><primary>désactivation des triggers</primary></indexterm>
-<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> Le <ulink
-url="http://www.slony.info/bugzilla/show_bug.cgi?id=19"> bug
-#19</ulink> indique que le dump d'un schéma peut contenir des
-triggers et des règles que l'on ne souhaite pas activer sur un
-noeud de log shipping.</para>
+<para>
+ L'outil <filename> tools/find-triggers-to-deactivate.sh</filename> a été
+ créé pour assister l'utilisateur dans cette tache. Il peut être lancé sur un
+ 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> L'outil <filename> tools/find-triggers-to-deactivate.sh
-</filename> a été créé pour assister l'utilisateur dans cette tache.
-Il peut être lancé sur un noeud qui sera utilisé comme schéma source,
-et il liste les règles et les triggers présents sur ce noeud qui devraient
-être désactivés.</para>
+<para>
+ Cela comprend le 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>
-<para> Cela comprend le triggers <function>logtrigger</function>
- et <function>denyaccess</function> qui sont normalement exclut
- du schéma extrait avec pgdump. Il est toutefois de la responsabilité
- de l'administrateur de vérifier que des triggers comme ceux-ci
- sont bien retirés du réplicat du log shipping.
- </para>
-
</sect2>
-<sect2> <title> L'outil <application>slony_logshipper </application></title>
+<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>
+ À partir de la version 1.2.12, &slony1; a un outil conçu pour aider à
+ appliquer les logs, nommé <application>slony_logshipper</application>.
+ Il fonctionne avec trois types de paramètres :
</para>
<itemizedlist>
-<listitem><para> des options : </para>
-<itemizedlist>
-<listitem><para><option>h</option> </para> <para> affiche cette aide et se termine </para> </listitem>
-<listitem><para><option>v</option> </para> <para> affiche la version et se termine </para> </listitem>
-<listitem><para><option>q</option> </para> <para> mode silencieux </para> </listitem>
-<listitem><para><option>l</option> </para> <para> ordonne au démon de rouvrir le fichier </para> </listitem>
-<listitem><para><option>r</option> </para> <para> ordonne au démon de continuer après une erreur </para> </listitem>
-<listitem><para><option>t</option> </para> <para> ordonne au démon d'entrer en mode d'arrêt intelligent ("smart shutdown") </para> </listitem>
-<listitem><para><option>T</option> </para> <para> ordonne au démon d'entrer en mode d'arrêt immédiat </para> </listitem>
-<listitem><para><option>c</option> </para> <para> détruit les sémaphores existantes et la file d'attente des messages (utiliser avec précaution) </para> </listitem>
-<listitem><para><option>f</option> </para> <para> rester au premier plan (ne pas fonctionner en mode démon) </para> </listitem>
-<listitem><para><option>w</option> </para> <para> entrer immédiatement en mode d'arrêt intelligent</para> </listitem>
-</itemizedlist>
-</listitem>
-<listitem><para> un fichier de configuration spécifique </para>
-<para> Ce fichier est composé des paramètres suivants :</para>
-<itemizedlist>
-<listitem><para> <command>logfile = './offline_logs/logshipper.log';</command></para>
-<para> L'endroit où le log shipper laissera ses traces d'exécutions.</para> </listitem>
-<listitem><para> <command>cluster name = 'T1';</command></para> <para> le nom du cluster </para> </listitem>
-<listitem><para> <command>destination database = 'dbname=slony_test3';</command></para> <para> Le paramètre conninfo
- optionnel pour se connecter à la base destination. Si ce paramètre est fourni,
- le log shipper se connectera à cette base et y appliquera les logs. </para> </listitem>
-<listitem><para> <command>archive dir = './offline_logs';</command></para> <para> Le répertoire d'archive
- est obligatoire lorsqu'on est en mode <quote>connecté à une database</quote> afin de pouvoir
- scanner noeud à la recherche d'archives manquantes (ou non appliquées). </para> </listitem>
-<listitem><para> <command>destination dir = './offline_result';</command></para> <para> Si ce paramètre est défini,
- le log shipper écrira les résultats du traitement des données à l'intérieur de fichiers
- de log placés dans ce répertoire.</para> </listitem>
-<listitem><para> <command>max archives = 3600;</command></para> <para> Ce paramètre lutte
- contre d'éventuelles fuites mémoire; le démon entrera en mode d'arrêt intelligent( <quote>smart shutdown</quote> )
- automatiquement après avoir traiter ce nombre d'archives. </para> </listitem>
-<listitem><para> <command>ignore table "public"."history";</command></para> <para> On peut exclure
- certaines tables du système de log shipping</para> </listitem>
-<listitem><para> <command>ignore namespace "public";</command></para> <para> On peut exclure
- un espace de noms du système de réplication </para> </listitem>
-<listitem><para> <command>rename namespace "public"."history" to "site_001"."history";</command></para> <para>
- On peut renommer des tables spécifiques.</para> </listitem>
-<listitem><para> <command>rename namespace "public" to "site_001";</command></para> <para>
- On peut renommer un espace de noms.</para> </listitem>
-<listitem><para> <command>post processing command = 'gzip -9 $inarchive';</command></para> <para>
- Les commandes de pré-traitement et post-traitement sont exécutées via la fonction <function>system(3)</function>. </para> </listitem>
-</itemizedlist>
-<para> Un <quote>@</quote> placé devant le nom de la commande permet d'ignorer un code de retour. Sinon, tout code
- de retour différent de zéro sera traité comme une erreur et provoquera l'arrêt du processus. </para>
+ <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>
-<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>
-<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> Le commande d'erreur indique quelle commande lancé lorsqu'une erreur est rencontrée.
- Toutes l'archivage réalisée depuis le dernier archive traité avec succès est disponible
- dans la variable <envar>$errortext</envar>. </para>
-
-<para> Dans l'exemple donné, un courriel est envoyé à l'administrateur
- lorsqu'une erreur est rencontrée.</para> </listitem>
+ <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>
+ <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>
-
+ <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>
Modified: traduc/trunk/slony/slon.xml
===================================================================
--- traduc/trunk/slony/slon.xml 2009-02-10 22:41:58 UTC (rev 1238)
+++ traduc/trunk/slony/slon.xml 2009-02-11 22:07:11 UTC (rev 1239)
@@ -35,18 +35,23 @@
<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 noeud du cluster &slony1;.</para>
+ 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>
+ <term><option>-d</option> <replaceable class="parameter">log_level</replaceable></term>
<listitem>
- <para>Le paramètre <envar>log_level</envar> spécifie quel niveau de messages de debug
- <application>slon</application> doit afficher dans son journal d'activité.</para>
- <para id="nineloglevels">Il y a neuf niveaux de log :
+ <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>
@@ -59,285 +64,420 @@
<listitem><para>Debug4</para></listitem>
</itemizedlist>
</para>
- <para> Les cinq premiers niveau de log ( de Fatal à
- Info) sont <emphasis>toujours</emphasis> affichés dans les logs.
- Dans les premières versions de &slony1;, le niveau de log
- <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
- pluspart des informations intéressantes sont produites à
- des niveaux supérieurs à celui-là.</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"> Interval entre les vérifications SYNC</replaceable></term>
+ <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érations.</para>
+ <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 noeud
- 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 synchronisations.</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 noeud n'est pas l'origine d'un set 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>
+ <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>
+ <term><option>-t</option><replaceable class="parameter">intervalle maximal
+ entre deux SYNC</replaceable></term>
<listitem>
- <para>A la fin de chaque période <envar>sync_interval_timeout</envar>
- , un événement <command>SYNC</command> est produit sur le noeud
- <quote>local</quote> même si 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>
+ À 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 le chute du
- système de réplication. </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 si il n'y a pas
- réellement de travail de réplication a faire. Plus la valeur de
- cette paramètre est basse, plus les évènements <command>SYNC</command>
- lorsque l'application n'est pas active. Ceci a deux 2 effets :</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>
+ <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>
+ <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 noeud soit
- <quote>synchronisé</quote> par un <command>SYNC</command> toutes les 10 secondes.</para>
- <para>Notez que des événements <command>SYNC</command> sont aussi générés
- sur chaque noeud abonné. Cependant puisqu'ils ne contiennent
- de données à répliquer par les autres noeuds, les évènements
- <command>SYNC</command> des noeuds abonnés ne sont pas terriblement intéressant.</para>
+
+ <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>
+ <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 maximumale d'un groupe <command>SYNC</command>,
- . La valeur par défaut est 6. Ainsi, si un noeud particulier a
- 200 événements <command>SYNC</command>s 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>comitter</quote>.</para>
- <para>La valeur par défaut est 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 a un noeud abonné de rattraper plus vite son retard.</para>
- <para>Les processus Slon sont souvent très petits; même en cas
- de valeur très forte pour cette option, <application>slon</application>
- devrait simplement grossir de quelques MB.</para>
- <para>Le gros avantage d'augmenter ce paramètre est que
- cela divise le nombre de transaction
- <command>COMMIT</command>s; passer de 1 to 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>s
- 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>s 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>s
- ont été interrompus sur un noeud origine, ce qui fait
- que les suivants sont volumineux. Vous rencontrerez
- ce problème : en regroupant des <command>SYNC</command>s très
- larges, le processus <application>slon</application> peut échouer.
- Au redémarrage, il essaie a nouveau de traiter ce large ensemble
- de <command>SYNC</command>s, 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; version 1.0, le démon <application>slon</application>
- '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>s pausent problème, le démon
- <application>slon</application> pourra (avec s'il est surveillé par
- un processus chien de garde) traiter un par un ces évènements
- <command>SYNC</command>s problématique, et ainsi éviter l'intervention
- d'un administrateur.</para>
+ <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>
+ <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>s.</para>
- <para> Si la réplication est en retard, le démon slon va progressivement augmenter le
- nombre de <command>SYNC</command>s 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> group de <command>SYNC</command>s).</para>
- <para> La valeur par défaut est 60000ms, c'est à dire une minute. </para>
+ <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>
+ 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>
+ 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 1 é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>
+ <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>
+
<varlistentry>
- <term><option>-c</option><replaceable class="parameter"> cycles de nettoyage</replaceable></term>
+ <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>Positionner cette valeur à zéro pour désactiver les nettoyages
- initiés par <application>slon</application>. Si vous utilisés un
- mécanisme tel que <application>pg_autovacuum</application> pour
- lancer les vacuums, vous n'aurez probablement pas besoin que
- slon initie des vacuums de lui-même. Sinon, il existe des tables
- utilisées par <productname>Slony-I</productname> qui collectent
- <emphasis>beaucoup</emphasis> de tuples morts, et qui doivent
- être nettoyées fréquemment, en particulier &pglistener;.</para>
- <para> A 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. A 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>
+ <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>
+ <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écute sur un hôte.</para>
+ <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>
+ <term><option>-f</option> <replaceable class="parameter">fichier de configuration</replaceable></term>
<listitem>
- <para>Fichier qui contient la configuration <application>slon</application>.</para>
+ <para>
+ Fichier qui contient la configuration <application>slon</application>.
+ </para>
- <para> La configuration 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 variable 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 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 noeud.</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>
+ <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>
+ <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>
+ <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>
+ <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>
+ <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 surveiller 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>
+ 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>
+ <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>
+ <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>
+ <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>
+ <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 que le temps de retard qu'un noeud doit avoir
- par rapport à son fournisseur. Cela implique que les événements seront
- ignorés tant que leur age sera inférieur à cet intervalle.</para>
+ <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 demande que tous les noeuds 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>
+ <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>
+ <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 ( "Exit Status" ) </title>
- <para><application>slon</application> renvoie 0 dans le shell si 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 un valeur de retour de 127 ou 255, suivant votre système d'exploitation ).</para>
+ <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>
More information about the Trad
mailing list