[Trad] [svn:pgfr] r1220 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Dim 18 Jan 00:43:30 CET 2009
Author: gleu
Date: 2009-01-18 00:43:30 +0100 (Sun, 18 Jan 2009)
New Revision: 1220
Modified:
traduc/trunk/slony/concepts.xml
traduc/trunk/slony/dropthings.xml
traduc/trunk/slony/locking.xml
traduc/trunk/slony/partitioning.xml
traduc/trunk/slony/plainpaths.xml
traduc/trunk/slony/releasechecklist.xml
traduc/trunk/slony/slony.xml
traduc/trunk/slony/startslons.xml
traduc/trunk/slony/subscribenodes.xml
traduc/trunk/slony/supportedplatforms.xml
traduc/trunk/slony/versionupgrade.xml
Log:
Relecture, ?\195?\169tape 2.
Modified: traduc/trunk/slony/concepts.xml
===================================================================
--- traduc/trunk/slony/concepts.xml 2009-01-17 18:49:02 UTC (rev 1219)
+++ traduc/trunk/slony/concepts.xml 2009-01-17 23:43:30 UTC (rev 1220)
@@ -6,153 +6,196 @@
<sect1 id="concepts">
<title>Les concepts</title>
-
<indexterm><primary>concepts et terminologie</primary></indexterm>
-<para>Afin de mettre en place une réplication &slony1;, il est nécessaire de comprendre les
- principales abstractions utilisées : </para>
+<para>
+ Afin de mettre en place une réplication &slony1;, il est nécessaire de
+ comprendre la terminologie utilisée :
+</para>
<itemizedlist>
- <listitem><para>Cluster,</para></listitem>
- <listitem><para>Noeud ("node"),</para></listitem>
- <listitem><para>Ensemble de réplication ("replication set"),</para></listitem>
- <listitem><para>Origine ("Origin"), Fournisseurs ("Providers") et Abonnés ("Subscribers"),</para></listitem>
- <listitem><para>Les démons slon,</para></listitem>
- <listitem><para>La commande slonik</para></listitem>
+ <listitem><para>Cluster ;</para></listitem>
+ <listitem><para>Noeud (« node ») ;</para></listitem>
+ <listitem><para>Ensemble de réplication (« replication
+ set ») ;</para></listitem>
+ <listitem><para>Origine (« Origin »), Fournisseurs
+ (« Providers ») et Abonnés
+ (« Subscribers ») ;</para></listitem>
+ <listitem><para>Les démons slon ;</para></listitem>
+ <listitem><para>La commande slonik.</para></listitem>
</itemizedlist>
-<para> Il est également nécessaire de connaître quelques mots de russe :</para>
+<para>
+ Il est également nécessaire de connaître quelques mots de russe :
+</para>
+
<itemizedlist>
-<listitem><para>slon signifie <quote>éléphant</quote> en russe,</para></listitem>
-<listitem><para>slony est le pluriel de slon, et désigne ainsi un groupe d'éléphants</para></listitem>
-<listitem><para>slonik désigne un <quote>petit éléphant</quote></para></listitem>
+ <listitem><para>slon signifie <quote>éléphant</quote> en russe ;</para></listitem>
+ <listitem><para>slony est le pluriel de slon, et désigne ainsi un groupe
+ d'éléphants ;</para></listitem>
+ <listitem><para>slonik désigne un <quote>petit éléphant</quote>.</para></listitem>
</itemizedlist>
-<para> L'utilisation de ces termes dans &slony1; est un <quote>coup de chapeau</quote>
- à Vadim Mikheev, qui est l'auteur du prototype <application>rserv</application>
- qui inspira une partie des algorithmes utilisé dans &slony1;.</para>
+<para>
+ L'utilisation de ces termes dans &slony1; est un <quote>coup de chapeau</quote>
+ à Vadim Mikheev qui est l'auteur du prototype <application>rserv</application>
+ qui inspira une partie des algorithmes utilisé dans &slony1;.
+</para>
<sect2>
<title>Cluster</title>
-<indexterm>
- <primary>cluster</primary>
-</indexterm>
+<indexterm><primary>cluster</primary></indexterm>
-<para>Selon &slony1;, un <quote>cluster</quote> est ensemble nommé d'instances de bases
- de données &postgres;; Une réplication a lieu entre ces bases.</para>
+<para>
+ Selon &slony1;, un <quote>cluster</quote> est ensemble nommé d'instances de
+ bases de données &postgres;. Une réplication a lieu entre ces bases.
+</para>
-<para>Le nom du cluster est spécifié dans chaque script Slonik via la directive :</para>
+<para>
+ Le nom du cluster est spécifié dans chaque script Slonik via la directive :
+</para>
+
<programlisting>
cluster name = 'quelque_chose';
</programlisting>
-<para>Si le nom du cluster est <envar>plop</envar>, alors &slony1;
-créera, dans chaque instance du cluster, le schéma <envar>_plop</envar>.</para>
+<para>
+ Si le nom du cluster est <envar>plop</envar>, alors &slony1; crée, dans
+ chaque instance du cluster, le schéma <envar>_plop</envar>.
+</para>
+
</sect2>
+
<sect2><title>Noeud</title>
-<indexterm>
-<primary>noeud</primary>
-</indexterm>
+<indexterm><primary>nœud</primary></indexterm>
-<para>Un noeud &slony1; est un base &postgres; nommée qui participe à la réplication.</para>
+<para>
+ Un nœud &slony1; est une base &postgres; nommée qui participe à la
+ réplication.
+</para>
-<para>Le nom du noeud est défini au début de chaque script Slonik, avec la directive :</para>
+<para>
+ Le nom du nœud est défini au début de chaque script Slonik, avec la
+ directive :
+</para>
+
<programlisting>
- NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
+NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
</programlisting>
-<para>La ligne <xref linkend="admconninfo"/> précise les informations
- de connexion qui seront utilisées par la fonction libpq
-<function>PQconnectdb()</function>.</para>
+<para>
+ La ligne <xref linkend="admconninfo"/> précise les informations de connexion
+ qui seront utilisées par la fonction libpq <function>PQconnectdb()</function>.
+</para>
-<para>Ainsi un cluster &slony1; se compose :</para>
+<para>
+ Ainsi un cluster &slony1; se compose :
+</para>
+
<itemizedlist>
- <listitem><para> d'un nom de cluster</para></listitem>
- <listitem><para> d'un ensemble de noeuds &slony1;, qui disposent chacun d'un schéma
- portant le nom du cluster</para></listitem>
+ <listitem><para>d'un nom de cluster ;</para></listitem>
+ <listitem><para> d'un ensemble de nœuds &slony1;, qui disposent chacun
+ d'un schéma portant le nom du cluster.</para></listitem>
</itemizedlist>
+
</sect2>
+
<sect2><title>Ensemble de réplication</title>
-<indexterm>
-<primary>Ensemble de réplication</primary>
-</indexterm>
+<indexterm><primary>Ensemble de réplication</primary></indexterm>
-<para>Un ensemble de réplication est défini comme un ensemble de tables et de séquences qui
- doivent être répliquées entre plusieurs noeuds dans un cluster &slony1;.</para>
+<para>
+ Un ensemble de réplication est défini comme un ensemble de tables et de
+ séquences qui doivent être répliquées entre plusieurs nœuds dans un
+ cluster &slony1;.
+</para>
-<para>Vous pouvez avoir plusieurs sets, et le <quote>flux</quote> de réplication
- n'est pas nécessaire identique pour tous les ensembles.</para>
+<para>
+ Vous pouvez avoir plusieurs sets, et le <quote>flux</quote> de réplication
+ n'est pas nécessairement identique pour tous les ensembles.
+</para>
+
</sect2>
-<sect2><title> Origine, Fournisseurs et Abonnés</title>
-<indexterm>
-<primary>Noeud d'origine</primary>
-</indexterm>
-<indexterm>
-<primary>Noeud fournisseur</primary>
-</indexterm>
+<sect2><title>Origine, Fournisseurs et Abonnés</title>
+<indexterm><primary>Nœud d'origine</primary></indexterm>
+<indexterm><primary>Nœud fournisseur</primary></indexterm>
-<para>Chaque ensemble de réplication a un noeud d'origine, qui est le <emphasis>seul</emphasis> endroit
- où les applications sont autorisées à modifier les données répliquées. On peut aussi
- rencontrer le terme <quote>noeud maître</quote>; Il s'agit de noeud principal qui
+<para>
+ Chaque ensemble de réplication a un nœud d'origine, qui est le
+ <emphasis>seul</emphasis> endroit où les applications sont autorisées à
+ modifier les données répliquées. On peut aussi rencontrer le terme
+ <quote>nœud maître</quote>. Il s'agit du nœud principal qui
fournit les données.
</para>
-<indexterm>
-<primary>Noeud Abonné</primary>
-</indexterm>
+<indexterm><primary>Nœud Abonné</primary></indexterm>
-<para>Les autres noeuds du cluster s'abonne à l'ensemble de réplication,
- ce qui indique qu'ils veulent recevoir les données.
+<para>
+ Les autres nœuds du cluster s'abonnent à l'ensemble de réplication, ce
+ qui indique qu'ils veulent recevoir les données.
</para>
-<para>Le noeud d'origine ne sera jamais considéré comme un
-<quote>abonné</quote> (On ignore ici le cas ou le cluster est restructuré
-et où l'origine est explicitement déplacée sur un autre noeud).
-Mais &slony1; supporte la notion d'abonnements en cascade, c'est à dire
-qu'un noeud qui est abonné à un ensemble de réplication, peut également se
-comporter comme un <quote>fournisseur</quote> du même ensemble de réplication
-pour d'autres noeuds du cluster.</para>
+<para>
+ Le nœud d'origine ne sera jamais considéré comme un
+ <quote>abonné</quote> (on ignore ici le cas ou le cluster est restructuré
+ et où l'origine est explicitement déplacée sur un autre nœud).
+ Mais &slony1; supporte la notion d'abonnements en cascade, c'est-à-dire
+ qu'un nœud qui est abonné à un ensemble de réplication, peut également
+ se comporter comme un <quote>fournisseur</quote> du même ensemble de
+ réplication pour d'autres nœuds du cluster.
+</para>
+
</sect2>
<sect2><title>Le démon slon</title>
-
<indexterm><primary>démon slon</primary></indexterm>
-<para>Pour chaque noeud du cluster, il y a un processus <xref
-linkend="slon"/> qui gère l'activité de réplication pour le noeud.
+<para>
+ Pour chaque nœud du cluster, il y a un processus <xref
+ linkend="slon"/> qui gère l'activité de réplication pour le nœud.
</para>
-<para> <xref linkend="slon"/> est un programme implémenté en C qui traite les
- évènements de réplication. Il y a deux principales sortes d'événements :
+<para>
+ <xref linkend="slon"/> est un programme implémenté en C qui traite les
+ évènements de réplication. Il y a deux principaux types d'événements :
</para>
<itemizedlist>
-<listitem><para>Les évènements de configuration</para>
+ <listitem>
+ <para>Les évènements de configuration</para>
-<para> Ils se produisent en général lorsqu'un script <xref linkend="slonik"/> est exécuté,
- et qu'il modifie la configuration du cluster. </para>
-</listitem>
+ <para>
+ Ils se produisent en général lorsqu'un script <xref linkend="slonik"/>
+ est exécuté et qu'il modifie la configuration du cluster.
+ </para>
+ </listitem>
-<listitem><para> Les événements <command>SYNC</command></para>
+ <listitem>
+ <para>Les événements <command>SYNC</command></para>
-<para> Les mises à jour des tables répliquées sont regroupées dans des événements <command>SYNC</command>s;
- Ces groupes de transactions sont appliquées ensemble sur les noeuds abonnés.
-</para>
-</listitem>
+ <para>
+ Les mises à jour des tables répliquées sont regroupées dans des
+ événements <command>SYNC</command> ; ces groupes de transactions
+ sont appliquées ensemble sur les nœuds abonnés.
+ </para>
+ </listitem>
+
</itemizedlist>
+
</sect2>
<sect2><title>La commande slonik</title>
-
<indexterm><primary>La commande slonik</primary></indexterm>
-<para> La commande <xref linkend="slonik"/> traite des scripts
- écrits dans un <quote>langage spécial</quote> qui est utilisé pour
- soumettre des événements de configuration du cluster &slony1; cluster.
- Cela comprend des actions telles que l'ajout et la suppression de noeuds,
- la modifications des voies de communications, l'ajout ou la suppression d'abonnements.
+<para>
+ La commande <xref linkend="slonik"/> traite des scripts écrits dans un
+ <quote>langage spécial</quote> qui est utilisé pour soumettre des événements
+ de configuration du cluster &slony1;. Cela comprend des actions telles que
+ l'ajout et la suppression de nœuds, la modification des voies de
+ communications, l'ajout ou la suppression d'abonnements.
</para>
+
</sect2>
+
</sect1>
Modified: traduc/trunk/slony/dropthings.xml
===================================================================
--- traduc/trunk/slony/dropthings.xml 2009-01-17 18:49:02 UTC (rev 1219)
+++ traduc/trunk/slony/dropthings.xml 2009-01-17 23:43:30 UTC (rev 1220)
@@ -4,115 +4,154 @@
par $Author$
révision $Revision$ -->
-<sect1 id="dropthings"> <title>Supprimer des éléments de la réplication</title>
-
+<sect1 id="dropthings">
+<title>Supprimer des éléments de la réplication</title>
<indexterm><primary>retirer des objets de la réplication</primary></indexterm>
-<para>Il y a plusieurs choses que vous pouvez supprimer de la réplication &slony1;.</para>
+<para>
+ Il y a plusieurs objets que vous pouvez supprimer de la réplication &slony1;.
+</para>
-<sect2><title>Retirer un noeud entier</title>
+<sect2>
+<title>Retirer un nœud entier</title>
+<indexterm><primary>retirer un nœud de la réplication</primary></indexterm>
-<indexterm><primary>retirer un noeud de la réplication</primary></indexterm>
+<para>
+ Si vous voulez retirer un nœud entier de la replication, la commande
+ <xref linkend="stmtdropnode"/> de <xref linkend="slonik"/> fera l'affaire.
+</para>
-<para>Si vous voulez retirer un noeud entier de la replication, la commande <xref
-linkend="slonik"/> <xref linkend="stmtdropnode"/> fera l'affaire.</para>
+<para>
+ Cela provoque la suppression des triggers (en général ceux qui empêchent la
+ mise à jour des données), la restauration des triggers
+ <quote>originels</quote>, la suppression du schéma utilisé par &slony1; et
+ l'arrêt du processus <xref linkend="slon"/> lui-même.
+</para>
-<para>Cela provoquera la suppression des triggers (en général ceux qui empêche la mise à jour
- des données), la restauration des triggers <quote>originels</quote>,
- la suppression du schéma utilisé par &slony1;, et l'arrêt du
- processus <xref linkend="slon"/> lui-même.</para>
+<para>
+ La base de données sera alors disponible pour toute utilisation standard.
+</para>
-<para>La base de données sera alors disponible pour toute utilisation standard.
+<para>
+ Il s'agit d'une opération majeure, avec un potentiel de destruction de données
+ considérable ; assurez-vous de retirer le bon nœud !
</para>
-<para>Il s'agit d'une opération majeure, avec un potentiel de destruction de données
- considérable; Assurez-vous que vous retirer le bon noeud !</para>
+<para>
+ L'opération échouera s'il y a des nœuds abonnés au nœud que vous
+ voulez retirer, ce qui constitue une petite sécurité contre les erreurs.
+</para>
-<para>L'opération échouera si il y a des noeuds abonnés au noeuds
- que vous voulez retirer, ce qui constitue une petite sécurité contre
- les erreurs.</para>
+<para>
+ Le paragraphe « <link linkend="faq17"><envar>sl_log_1</envar> n'est pas
+ purgée</link> » de la FAQ décrit des tâches supplémentaires de
+ maintenance que vous devez effectuer sur <xref linkend="table.sl-confirm"/>
+ si vous utilisez une version antérieure à la version 1.0.5.
+</para>
-<para>La paragraphe <link linkend="faq17"> <envar>sl_log_1</envar> n'est pas purgée
- </link> de la FAQ décrit des taches supplémentaires de maintenance que vous
- devez effectuer sur <xref linkend="table.sl-confirm"/> si vous utilisez une
- version antérieures à la version 1.0.5.</para></sect2>
+</sect2>
-<sect2><title>Retirer un ensemble de réplication</title>
-
+<sect2>
+<title>Retirer un ensemble de réplication</title>
<indexterm><primary>retirer un ensemble de réplication</primary></indexterm>
-<para>Si vous souhaitez arrêter la réplication d'un ensemble de réplication particulier,
- la commande <xref linkend="slonik"/> <xref linkend="stmtdropset"/> est faite pour vous.
+<para>
+ Si vous souhaitez arrêter la réplication d'un ensemble de réplication
+ particulier, la commande <xref linkend="stmtdropset"/> de <xref
+ linkend="slonik"/> est faite pour vous.
</para>
-<para>Comme avec <xref linkend="stmtdropnode"/>, cela provoque le retrait
- des triggers &slony1; sur les tables et la restauration des triggers
- <quote>originels</quote>. La différence est que cela se produit sur
- <emphasis>tous</emphasis> les noeuds du cluster, plutôt que sur un seul.
- Une autre différence est que cela ne nettoie pas les autres schémas du cluster,
- car ils sont toujours utilisés.</para>
+<para>
+ Comme avec <xref linkend="stmtdropnode"/>, cela provoque le retrait des
+ triggers &slony1; sur les tables et la restauration des triggers
+ <quote>originels</quote>. La différence est que cela se produit sur
+ <emphasis>tous</emphasis> les nœuds du cluster, plutôt que sur un seul.
+ Une autre différence est que cela ne nettoie pas les autres schémas du
+ cluster car ils sont toujours utilisés.
+</para>
-<para>Cette opération est nettement plus dangereuse que <xref
-linkend="stmtdropnode"/>, car <emphasis>il n'y a pas</emphasis>
- de <quote>sécurités</quote> équivalentes. Si vous demandez à
- <xref linkend="stmtdropset"/> de retirer le <emphasis>mauvais</emphasis>
- ensemble de réplication, il n'y a rien qui vous empêchera de réaliser
- une opération pourrait avoir des effets <quote>malencontreux</quote>
- sur les données et sur votre carrière. À manipuler avec précaution...</para>
+<para>
+ Cette opération est nettement plus dangereuse que <xref
+ linkend="stmtdropnode"/> car <emphasis>il n'y a pas</emphasis> de
+ <quote>sécurités</quote> équivalentes. Si vous demandez à <xref
+ linkend="stmtdropset"/> de retirer le <emphasis>mauvais</emphasis>
+ ensemble de réplication, il n'y a rien qui vous empêchera de réaliser
+ une opération qui pourrait avoir des effets <quote>malencontreux</quote>
+ sur les données et sur votre carrière. À manipuler avec précaution...
+</para>
+
</sect2>
-<sect2><title>Désabonner un noeud d'un ensemble de réplication</title>
+<sect2>
+<title>Désabonner un nœud d'un ensemble de réplication</title>
+<indexterm><primary>désabonner un nœud d'un ensemble de réplication</primary></indexterm>
-<indexterm><primary>désabonner un noeud d'un ensemble de réplication</primary></indexterm>
+<para>
+ L'opération <xref linkend="stmtunsubscribeset"/> est un peu moins puissante
+ que <xref linkend="stmtdropset"/> ou <xref linkend="stmtdropnode"/> ;
+ elle implique la suppression des triggers &slony1; et la restauration des
+ triggers <quote>originels</quote> sur un seul nœud, pour un seul
+ ensemble de réplication.
+</para>
-<para>L'opération <xref linkend="stmtunsubscribeset"/> est un peu moins
- puissante que <xref linkend="stmtdropset"/> ou <xref
-linkend="stmtdropnode"/>; elle implique la suppression des triggers &slony1; et
- et la restauration des triggers <quote>originels</quote> sur un seul noeuds, pour
- un seul ensemble de réplication.</para>
+<para>
+ Tout comme <xref linkend="stmtdropnode"/>, cette opération échouera si un
+ nœud est abonné à l'ensemble de réplication via le nœud que vous
+ voulez retirer.
-<para>Tout comme <xref linkend="stmtdropnode"/>, cette opération échouera
- si un noeud est abonné à l'ensemble de réplication via le noeud
- que vous voulez retirer.
-
-<warning>
-<para>Pour toutes les opérations ci-dessus, <quote>revenir en arrière</quote>
- nécessitera une copie du noeud à partir d'un ensemble de données
- <emphasis>complet</emphasis> en provenance d'un fournisseur. Le fait que les
- données aient été répliquées encore récemment ne suffit pas;
- &slony1; voudra des données reconstituées à partir de zéro.</para>
-</warning>
+ <warning>
+ <para>
+ Pour toutes les opérations ci-dessus, <quote>revenir en arrière</quote>
+ nécessitera une copie du nœud à partir d'un ensemble de données
+ <emphasis>complet</emphasis> en provenance d'un fournisseur. Le fait que
+ les données aient été répliquées encore récemment ne suffit pas ;
+ &slony1; voudra des données reconstituées à partir de zéro.
+ </para>
+ </warning>
</para>
</sect2>
-<sect2><title> Retirer une table de la réplication</title>
+
+<sect2>
+<title> Retirer une table de la réplication</title>
<indexterm><primary>retirer une table de la réplication</primary></indexterm>
-<sect3><title> En utilisant les outils altperl</title>
+<sect3>
+<title>En utilisant les outils altperl</title>
<para>
-Si les outils <link linkend="altperl"> altperl </link> sont installés,
-vous pouvez utiliser le script d'aide <link linkend="slonik-drop-table">
-slonik_drop_table </link> pour supprimer une table dans un ensemble de réplication.
-Lancez simplement <command>slonik_drop_table</command> sans arguments pour afficher
-la méthode d'utilisation du script. Après avoir retiré la table, vous devez également
-la retire du fichier <filename>slon_tools.conf</filename>.
+ Si les outils <link linkend="altperl">altperl</link> sont installés, vous
+ pouvez utiliser le script d'aide <link
+ linkend="slonik-drop-table">slonik_drop_table</link> pour supprimer une table
+ dans un ensemble de réplication. Lancez simplement
+ <command>slonik_drop_table</command> sans arguments pour afficher la méthode
+ d'utilisation du script. Après avoir retiré la table, vous devez également la
+ retirer du fichier <filename>slon_tools.conf</filename>.
</para>
</sect3>
-<sect3><title> En utilisant directement les commandes slonik</title>
-<para>À partir de &slony1; 1.0.5, il existe une commande Slonik <xref
-linkend="stmtsetdroptable"/> qui permet de supprimer une table de la réplication
- sans forcer l'utilisateur à supprimer la totalité de l'ensemble de réplication.
+<sect3>
+<title>En utilisant directement les commandes slonik</title>
+
+<para>
+ À partir de &slony1; 1.0.5, il existe une commande Slonik <xref
+ linkend="stmtsetdroptable"/> qui permet de supprimer une table de la
+ réplication sans forcer l'utilisateur à supprimer la totalité de l'ensemble
+ de réplication.
</para>
-<para>Si vous utiliser une version antérieure, il y a une <quote>astuce</quote>
-pour réaliser cela :</para>
+<para>
+ Si vous utiliser une version antérieure, il y a une <quote>astuce</quote>
+ pour réaliser cela :
+</para>
-<para>Vous pouvez réaliser cela <quote>à la main</quote> en trouvant l'identifiant
- de la table dont vous voulez vous débarrassez, que vous pouvez trouver dans
- <xref linkend="table.sl-table"/>, et exécuter les trois requêtes suivantes sur chaque hôte :
+<para>
+ Vous pouvez réaliser cela <quote>à la main</quote> en trouvant l'identifiant
+ de la table dont vous voulez vous débarrasser, que vous pouvez trouver dans
+ <xref linkend="table.sl-table"/> et exécuter les trois requêtes suivantes sur
+ chaque hôte&,nbsp;:
+
<programlisting>
select _slonyschema.alterTableRestore(40);
select _slonyschema.tableDropKey(40);
@@ -120,36 +159,45 @@
</programlisting>
</para>
-<para>Bien entendu, le nom du schéma dépend de celui qui a été défini pour le cluster
- &slony1;. L'identifiant de la table, dans ce cas 40, doit être remplacé par l'identifiant
- de la table que vous souhaitez retirer.
- </para>
+<para>
+ Bien entendu, le nom du schéma dépend de celui qui a été défini pour le
+ cluster &slony1;. L'identifiant de la table, dans ce cas 40, doit être
+ remplacé par l'identifiant de la table que vous souhaitez retirer.
+</para>
-<para>Vous devrez exécuter ces trois requêtes sur tous les noeuds, de préférence
- en commençant par le noeud d'origine, afin que l'événement
- se propage correctement. Réaliser cette opération avec une
- commande <xref linkend="slonik"/> avec un nouvel événement
- &slony1; permet de faire cela. Soumettre les trois requêtes
- en utilisant <xref linkend="stmtddlscript"/> permet cela également;
- Se reporter au chapitre <xref linkend="ddlchanges"/> pour plus de détails.
- Il est également possible de se connecter à chaque base de données
- et de soumettre manuellement les requêtes.
+<para>
+ Vous devrez exécuter ces trois requêtes sur tous les nœuds, de
+ préférence en commençant par le nœud d'origine, afin que l'événement
+ se propage correctement. Réaliser cette opération avec une commande <xref
+ linkend="slonik"/> pour un nouvel événement &slony1; permet de faire cela.
+ Soumettre les trois requêtes en utilisant <xref linkend="stmtddlscript"/>
+ permet cela également ; se reporter au chapitre <xref
+ linkend="ddlchanges"/> pour plus de détails. Il est également possible de
+ se connecter à chaque base de données et de soumettre manuellement les
+ requêtes.
</para>
+
</sect3>
+
</sect2>
-<sect2><title>Retirer une séquence de la réplication</title>
-
+<sect2>
+<title>Retirer une séquence de la réplication</title>
<indexterm><primary>retirer une séquence de la réplication</primary></indexterm>
-<para>À l'image de <xref linkend="stmtsetdroptable"/>, la version 1.0.5
-introduit l'opération <xref linkend="stmtsetdropsequence"/>.</para>
+<para>
+ À l'image de <xref linkend="stmtsetdroptable"/>, la version 1.0.5 introduit
+ l'opération <xref linkend="stmtsetdropsequence"/>.
+</para>
-<para>Si vous utilisez une version antérieure, voici les instructions pour
- retirer des séquences:</para>
+<para>
+ Si vous utilisez une version antérieure, voici les instructions pour retirer
+ des séquences :
+</para>
-<para>Ci-dessous les données nécessaires pour supprimer les
- séquence numérotées 93 and 59 :
+<para>
+ Ci-dessous les données nécessaires pour supprimer les séquence numérotées de
+ 93 à 59 :
<programlisting>
delete from _oxrsorg.sl_seqlog where seql_seqid in (93, 59);
@@ -157,9 +205,13 @@
</programlisting>
</para>
-<para> Ces deux requêtes doivent être soumises à tous les noeuds via
-&funddlscript; / <xref linkend="stmtddlscript"/>, afin d'éliminer la
-séquence partout en <quote>même temps</quote>. Elles peuvent également être
-appliquées à la main sur chaque noeud.</para>
+<para>
+ Ces deux requêtes doivent être soumises à tous les nœuds via
+ &funddlscript; / <xref linkend="stmtddlscript"/>, afin d'éliminer la
+ séquence partout en <quote>même temps</quote>. Elles peuvent également être
+ appliquées à la main sur chaque nœud.
+</para>
+
</sect2>
+
</sect1>
Modified: traduc/trunk/slony/locking.xml
===================================================================
--- traduc/trunk/slony/locking.xml 2009-01-17 18:49:02 UTC (rev 1219)
+++ traduc/trunk/slony/locking.xml 2009-01-17 23:43:30 UTC (rev 1220)
@@ -4,194 +4,266 @@
par $Author$
révision $Revision$ -->
-<sect1 id="locking"> <title>Problèmes de verrous</title>
-
+<sect1 id="locking">
+<title>Problèmes de verrous</title>
<indexterm><primary>problèmes de verrous</primary></indexterm>
-<para> L'un des avantages de &postgres; et de son contrôleur de concurrence de
- multiple version ( "Multi-Version Concurrency Control", nommé
- <acronym>MVCC</acronym> par la suite ) est qu'il élimine de nombreuses
- raison de verrouiller les objets de base de données. Sur certains
- systèmes de gestion de bases de données, vous devez verrouiller une table
- lorsque vous souhaitez insérer des données dans celle-ci; cela peut entraver
+<para>
+ L'un des avantages de &postgres; et de son contrôle d'accès simultané
+ (« Multi-Version Concurrency Control », nommé
+ <acronym>MVCC</acronym> par la suite) est qu'il élimine de nombreuses raisons
+ de verrouiller les objets de base de données. Sur certains systèmes de
+ gestion de bases de données, vous devez verrouiller une table lorsque vous
+ souhaitez insérer des données dans celle-ci ; cela peut gêner
<emphasis>sévèrement</emphasis> les performances. Sur d'autres systèmes,
- les lectures bloque les écritures concurrentes. Avec <acronym>MVCC</acronym>, &postgres;
- supprime tous une catégorie de verrous, dans le sens ou les
- <quote>vieilles lectures</quote> peuvent accéder aux <quote>anciens tuples</quote>.
- La pluspart du temps, cela évite aux aimables utilisateurs de
- &postgres; de trop se préoccuper des verrous.</para>
+ les lectures bloquent les écritures concurrentes. Avec
+ <acronym>MVCC</acronym>, &postgres; supprime toute une catégorie de verrous,
+ dans le sens où les <quote>vieilles lectures</quote> peuvent accéder aux
+ <quote>anciennes lignes</quote>. La plupart du temps, cela évite aux aimables
+ utilisateurs de &postgres; de trop se préoccuper des verrous.
+</para>
-<para> Malheureusement, il existe plusieurs sortes d'événements &slony1;
- qui nécessite des verrous exclusifs sur les tables &postgres;,
- ce qui entraine que la modification de la configuration &slony1;,
- peut provoquer des <quote>verrous génants</quote>.
- En particulier:</para>
+<para>
+ Malheureusement, il existe plusieurs sortes d'événements &slony1; qui
+ nécessitent des verrous exclusifs sur les tables &postgres;, ce qui entraine
+ que la modification de la configuration &slony1; peut provoquer des
+ <quote>verrous gênants</quote>. En particulier :
+</para>
-<itemizedlist>
+ <itemizedlist>
-<listitem><para><link linkend="stmtsetaddtable"> <command>set add
-table</command> </link></para>
+ <listitem>
+ <para><link linkend="stmtsetaddtable"><command>set add table</command></link></para>
-<para> Un verrou exclusif et momentané doit être posé sur
- une table du noeud <quote>origine</quote> afin de d'ajouter le trigger
- qui collecte les mises à jour de cette table. I doit simplement être
- posé assez longtemps pour établir le nouveau trigger.</para>
-</listitem>
+ <para>
+ Un verrou exclusif et momentané doit être posé sur une table du
+ nœud <quote>origine</quote> afin d'ajouter le trigger qui
+ collecte les mises à jour de cette table. Il doit simplement être posé
+ assez longtemps pour établir le nouveau trigger.
+ </para>
+ </listitem>
-<listitem><para><link linkend="stmtmoveset"> <command> move
-set</command> </link></para>
+ <listitem>
+ <para><link linkend="stmtmoveset"><command> move set</command></link></para>
-<para> Lorsqu'un ensemble sur un noeud origine est déplacé vers un autre noeud,
- des verrous exclusifs sont posé sur chaque table répliquée à la fois sur
- l'ancien et le nouveau noeud origine afin de modifier les triggers sur ces tables.
- </para></listitem>
+ <para>
+ Lorsqu'un ensemble sur un nœud origine est déplacé vers un autre
+ nœud, des verrous exclusifs sont posés sur chaque table répliquée
+ à la fois sur l'ancien et le nouveau nœud origine afin de
+ modifier les triggers sur ces tables.
+ </para>
+ </listitem>
-<listitem><para><link linkend="stmtlockset"> <command> lock set
-</command> </link> </para>
+ <listitem>
+ <para><link linkend="stmtlockset"><command>lock set</command></link></para>
-<para> Cette opération demande explicitement des verrous sur chaque
- table dans un ensemble de réplication donné sur le noeud origine.
- </para>
-</listitem>
+ <para>
+ Cette opération demande explicitement des verrous sur chaque table dans
+ un ensemble de réplication donné sur le nœud origine.
+ </para>
+ </listitem>
-<listitem><para><link linkend="stmtddlscript"> <command>execute
-script</command> </link> </para>
+ <listitem>
+ <para><link linkend="stmtddlscript"><command>execute script</command></link></para>
-<para> Cette opération lance un ensemble de requête SQL;
- pour qu'elle fonctionne, les triggers &slony1; doivent être
- retirés, ensuite les requêtes sont exécutées ( ce qui peut modifier
- les données ), enfin les triggers sont restaurés. Pour cela,
- l'opération doit acquérir des verrous sur toutes les tables de
- chaque noeuds. </para>
-</listitem>
+ <para>
+ Cette opération lance un ensemble de requêtes SQL ; pour qu'elle
+ fonctionne, les triggers &slony1; doivent être retirés, ensuite les
+ requêtes sont exécutées (ce qui peut modifier les données), enfin les
+ triggers sont restaurés. Pour cela, l'opération doit acquérir des
+ verrous sur toutes les tables de chaque nœud.
+ </para>
+ </listitem>
-<listitem><para> Pendant un événement <command>SUBSCRIBE_SET</command> sur
- un nouvel abonné </para>
+ <listitem>
+ <para>
+ Pendant un événement <command>SUBSCRIBE_SET</command> sur un nouvel
+ abonné
+ </para>
-<para> Dans un sens, c'est le scénario le moins perturbant, car
- avant que l'ensemble de réplication soit complet, on peut
- penser que le noeud <quote>inutilisable</quote> et que
- &slony1; peut raisonnablement demander l'accès exclusif sur le noeud.
- </para>
+ <para>
+ Dans un sens, c'est le scénario le moins perturbant car, avant que
+ l'ensemble de réplication soit complet, on peut penser que le nœud
+ <quote>inutilisable</quote> et que &slony1; peut raisonnablement
+ demander l'accès exclusif sur le nœud.
+ </para>
-<para> Un changement dans la version 1.2 provoque une requête SQL <command>LOCK
-TABLE</command> explicite qui est placé dans la boucle qui valide que toutes les
-tables sont présentes. Cela signifie que
-<emphasis>toutes</emphasis> les tables de l'ensemble de réplication
-sont verrouiller avec un verrou exclusif pour la durée totale du processus
-de souscription. En verrouillant les tables très tôt, on s'assure que
-le souscription n'échouera pas à cause d'un autre processus ayant un
-verrou sur une table.
-</para>
+ <para>
+ Un changement dans la version 1.2 provoque une requête SQL <command>LOCK
+ TABLE</command> explicite qui est placée dans la boucle qui valide que
+ toutes les tables sont présentes. Cela signifie que
+ <emphasis>toutes</emphasis> les tables de l'ensemble de réplication sont
+ verrouillées avec un verrou exclusif pour la durée totale du processus
+ de souscription. En verrouillant les tables très tôt, on s'assure que
+ la souscription n'échouera pas à cause d'un autre processus ayant un
+ verrou sur une table.
+ </para>
-<para> Dans tous les cas, notez que ce script opère
-<quote>sur un nouveau noeud abonné</quote>. Les verrous sont posés
-<quote>sur un nouveau noeud abonné</quote>. Ils s'appliquent <emphasis>pas</emphasis>
-au noeud fournisseur ou au noeud origine. </para>
+ <para>
+ Dans tous les cas, notez que ce script opère <quote>sur un nouveau
+ nœud abonné</quote>. Les verrous sont posés <quote>sur un
+ nouveau nœud abonné</quote>. Ils ne s'appliquent
+ <emphasis>pas</emphasis> au nœud fournisseur ou au nœud
+ origine.
+ </para>
+ </listitem>
-</listitem>
+ <listitem>
+ <para>
+ <application>pg_autovacuum</application> ne fait pas partie de
+ &slony1; mais il se réveille une fois par minute et peut, à tout
+ moment, se lancer dans le nettoyage d'une table, et ainsi poser un
+ verrou <envar>ShareUpdateExclusiveLock</envar>. Ceci peut bloquer les
+ autres événements pendant une période imprévisible.
+ </para>
+ </listitem>
+ </itemizedlist>
-<listitem><para> <application>pg_autovacuum</application> ne fait pas partie
-de &slony1;, mais il se réveille une fois par minute et peut, à tout moment,
-se lancer dans le nettoyage d'une table, et ainsi poser un verrou
-<envar>ShareUpdateExclusiveLock</envar>. Ceci peut bloquer les autres événements
-pendant un période imprévisible.</para>
-</listitem>
+<para>
+ Chacune de ces actions nécessite, à un certain de point, de modifier chaque
+ table de l'ensemble de réplication, ce qui implique l'acquisition d'un verrou
+ exclusif sur les tables. Certains utilisateurs ont tenté d'effectuer ces
+ opérations sur des nœuds qui étaient activement sollicités par la
+ couche applicative ; ils ont rencontré des problèmes d'inter-blocages
+ (« deadlocks ») et/ou des arrêts de réplication.
+</para>
-</itemizedlist>
+<para>
+ La question évident est : <quote>que faire pour éviter ces
+ inter-blocages ?</quote>
+</para>
-<para> Chacune de ces actions nécessite, à un certain de point, de
- modifier chaque table de l'ensemble de réplication, ce qui implique
- l'acquisition d'un verrou exclusif sur les tables. Certains utilisateurs
- ont tenté d'effectuer ces opérations sur des noeuds qui étaient activement
- sollicités par la couche applicative; ils ont rencontré des problèmes
- d'inter-blocages ("deadlocks") et/ou des arrêts de réplication. </para>
+<para>
+ Plusieurs possibilités sont envisageables :
+</para>
-<para> La question évident est : <quote>Que faire pour éviter ces inter-blocages ?</quote> </para>
-
-<para> Plusieurs possibilités sont envisageables : </para>
-
<itemizedlist>
-<listitem><para> Annoncer une coupure de service pour éviter les inter-blocages
+ <listitem>
+ <para>
+ Annoncer une coupure de service pour éviter les inter-blocages.
</para>
-<para>Si vous pouvez empêcher temporairement les applications
- d'accéder à la base de données, cela vous offrira une fenêtre de temps
- pendant laquelle aucune opération ne sera effectuée sur la base de données,
- à l'exception des processus d'administration que vous controllerez.
- </para> </listitem>
+ <para>
+ Si vous pouvez empêcher temporairement les applications d'accéder à la
+ base de données, cela vous offrira une fenêtre de temps pendant laquelle
+ aucune opération ne sera effectuée sur la base de données, à l'exception
+ des processus d'administration que vous controllerez.
+ </para>
+ </listitem>
-<listitem><para> Tenter l'operation, en espérant que cela fonctionne </para>
+ <listitem>
+ <para>
+ Tenter l'operation, en espérant que cela fonctionne.
+ </para>
-<para> Puisque rien n'empêche les application de laisser de verrous sur
- votre chemin, vous pourrez vous retrouver dans une situation de blocage.
- Mais si le nombre de verrous restant est faible, vous pouvez négocier
- avec les utilisateurs pour <quote>avoir la priorité</quote>. </para>
-</listitem>
+ <para>
+ Puisque rien n'empêche les application de laisser des verrous sur votre
+ chemin, vous pourrez vous retrouver dans une situation de blocage. Mais
+ si le nombre de verrous restant est faible, vous pouvez négocier avec
+ les utilisateurs pour <quote>avoir la priorité</quote>.
+ </para>
+ </listitem>
-<listitem><para> Utiliser pgpool </para>
+ <listitem>
+ <para>
+ Utiliser pgpool.
+ </para>
-<para> Si vous pouvez utiliser pgpool ou un <quote>gestionnaire de connexion
-</quote> similaire, vous pouvez configurer le programme pour
-qu'il n'utilise plus la base pendant un petit moment, et ainsi
-le laisser <quote>bloquer</quote> les applications pour vous.
-L'idéal étant que le gestionnaire de connexion retiennent les requêtes
-assez longtemps pour que la coupure de service apparaisse comme un
-simple ralentissement. </para></listitem>
+ <para>
+ Si vous pouvez utiliser pgpool ou un <quote>gestionnaire de
+ connexions</quote> similaire, vous pouvez configurer le programme pour
+ qu'il n'utilise plus la base pendant un petit moment, et ainsi le
+ laisser <quote>bloquer</quote> les applications pour vous. L'idéal étant
+ que le gestionnaire de connexions retienne les requêtes assez longtemps
+ pour que la coupure de service apparaisse comme un simple ralentissement.
+ </para>
+ </listitem>
-<listitem><para> Gestion rapide de coupure de service </para>
+ <listitem>
+ <para>
+ Gestion rapide de coupure de service.
+ </para>
-<para> La procédure suivante minimisera le temps de coupure de service:
+ <para>
+ La procédure suivante minimisera le temps de coupure de service :
-<itemizedlist>
+ <itemizedlist>
-<listitem><para> Modifier <filename>pg_hba.conf</filename> afin que seul
-<link linkend="slonyuser">l'utilisateur <command>slony</command> user </link>
-ait accès à la base de données.</para> </listitem>
+ <listitem>
+ <para>
+ Modifier <filename>pg_hba.conf</filename> afin que seul l'<link
+ linkend="slonyuser">utilisateur <command>slony</command></link>
+ ait accès à la base de données.
+ </para>
+ </listitem>
-<listitem><para> Envoyer un <command>kill -SIGHUP</command> au postmaster de
-&postgres;.</para>
+ <listitem>
+ <para>
+ Envoyer un <command>kill -SIGHUP</command> au postmaster de
+ &postgres;.
+ </para>
-<para> Ceci ne tuera pas les longues requêtes qui pourraient être en cours d'exécution
- mais cela empêchera les nouvelles d'entrer. Cela a un impact sur l'application
- puisque les requêtes entrantes seront rejetées jusqu'à la fin de la procédure.
-</para>
-</listitem>
+ <para>
+ Ceci ne tuera pas les longues requêtes qui pourraient être en
+ cours d'exécution mais cela empêchera les nouvelles d'entrer. Cela
+ a un impact sur l'application puisque les requêtes entrantes seront
+ rejetées jusqu'à la fin de la procédure.
+ </para>
+ </listitem>
-<listitem><para> Si <quote>tout va bien</quote>, alors on peut
- effectuer sans danger l'opération &slony1;. </para> </listitem>
+ <listitem>
+ <para>
+ Si <quote>tout va bien</quote>, alors on peut effectuer sans danger
+ l'opération &slony1;.
+ </para>
+ </listitem>
-<listitem><para> si une requête est toujours en cours, vous devrez peut-être
- effectuer un <command>kill -SIGQUIT</command> sur un des processus
- &postgres;. Cela relancera le moteur et tuera toutes les requêtes
- en attente. Vous devrez probablement relancer les processus
- <xref linkend="slon"/> qui sont attachés à ce noeud. </para>
+ <listitem>
+ <para>
+ Si une requête est toujours en cours, vous devrez peut-être
+ effectuer un <command>kill -SIGQUIT</command> sur un des processus
+ &postgres;. Cela relancera le moteur et tuera toutes les requêtes
+ en attente. Vous devrez probablement relancer les processus
+ <xref linkend="slon"/> qui sont attachés à ce nœud.
+ </para>
-<para> A ce point, l'opération &slony1; peut être effectuée sans danger;
- Il n'y aura aucun autre processus concurrent.
- </para></listitem>
+ <para>
+ À ce point, l'opération &slony1; peut être effectuée sans
+ danger ; il n'y aura aucun autre processus concurrent.
+ </para>
+ </listitem>
-<listitem><para> Recharger l'ancienne version du fichier <filename>pg_hba.conf</filename>
- pour autoriser les utilisateurs, et envoyer un <command>kill -SIGHUP</command>
- au processus postmaster pour qu'il recharge la configuration de sécurité. </para> </listitem>
+ <listitem>
+ <para>
+ Recharger l'ancienne version du fichier
+ <filename>pg_hba.conf</filename> pour autoriser les utilisateurs,
+ et envoyer un <command>kill -SIGHUP</command> au processus
+ postmaster pour qu'il recharge la configuration de sécurité.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ La section &rddlchanges; suggère des techniques supplémentaires qui
+ peuvent être utiles, telles que le déplacement des tables vers d'autres
+ ensemble de réplication afin de minimiser le nombre de tables qu'il faut
+ verrouiller.
+ </para>
+ </listitem>
</itemizedlist>
+<para>
+ Malheureusement, il n'y a pas de solution miracle. S'il est
+ <emphasis>nécessaire</emphasis> de soumettre une requête <xref
+ linkend="stmtmoveset"/>, alors il est probablement
+ <emphasis>nécessaire</emphasis> d'accepter une courte coupure de service.
+ Au fur et à mesure que les relations entre &slony1; et <link
+ linkend="pgpool">pgpool</link> s'améliorent, ce couple semble être la
+ meilleure méthode pour éviter les inter-blocages.
</para>
-</listitem>
-<listitem><para> La section &rddlchanges; suggère des techniques
- supplémentaires qui peuvent être utiles, telles que le déplacement
- des tables vers d'autres ensemble de réplication afin de minimiser
- le nombre de tables qu'il faut verrouiller.</para></listitem>
-
-</itemizedlist>
-
-<para> Malheureusement, il n'y a pas de solution miracle.
- Si il est <emphasis>nécessaire</emphasis> de soumettre une requête
- <xref linkend="stmtmoveset"/>, alors il est probablement
-<emphasis>nécessaire</emphasis> d'accepter une courte coupure de service.
-Au fur et à mesure que les relations entre &slony1; et <link linkend="pgpool"> pgpool </link>,
-s'améliore, ce couple semble être la meilleure méthode pour éviter les inter-blocages.
-</para>
-</sect1>
\ No newline at end of file
+</sect1>
Modified: traduc/trunk/slony/partitioning.xml
===================================================================
--- traduc/trunk/slony/partitioning.xml 2009-01-17 18:49:02 UTC (rev 1219)
+++ traduc/trunk/slony/partitioning.xml 2009-01-17 23:43:30 UTC (rev 1220)
@@ -8,107 +8,201 @@
<title>Support du partitionnement </title>
<indexterm><primary>partitionnement</primary></indexterm>
-<para> &slony1; ne supporte pas directement la méthode de partitionnement
- par héritage de &postgres;, cependant il n'empêche pas non plus les
+<para>
+ &slony1; ne supporte pas directement la méthode de partitionnement
+ par héritage de &postgres;. Cependant, il n'empêche pas non plus les
utilisateur de répliquer de tels héritages et ainsi que les tables
- qui y sont associées.</para>
+ qui y sont associées.
+</para>
-<para> Un des tests du <xref linkend="testbed"/>, appelé
-<filename>testinherit</filename>, vérifie que &slony1; se comporte
-comme prévu lors de la réplication de données partitionnées. Ce test
-crée une table maître <envar>sales_data</envar> dont plusieurs tables filles héritent : </para>
+<para>
+ Un des tests du <xref linkend="testbed"/>, appelé
+ <filename>testinherit</filename>, vérifie que &slony1; se comporte
+ comme prévu lors de la réplication de données partitionnées. Ce test
+ crée une table maître <envar>sales_data</envar> dont plusieurs tables filles
+ héritent :
+</para>
<itemizedlist>
-<listitem><para> <envar>us_east</envar></para> </listitem>
-<listitem><para> <envar>us_west</envar></para> </listitem>
-<listitem><para> <envar>canada</envar></para> </listitem>
+ <listitem><para><envar>us_east</envar></para></listitem>
+ <listitem><para><envar>us_west</envar></para></listitem>
+ <listitem><para><envar>canada</envar></para></listitem>
</itemizedlist>
-<para> Cet exemple est un peu simpliste car il fournit uniquement des règles
- d'insertion dans les différentes partitions; il ne permet pas de migrer des
- tuples d'une partition à une autre si ils sont modifiés via une commande
- <command>UPDATE</command> statement. D'un autre coté, à la différence de
- de beaucoup de partitionnement, celui-ci permet à la table <quote>parente</quote>
- de contenir des tuples. </para>
+<para>
+ Cet exemple est un peu simpliste car il fournit uniquement des règles
+ d'insertion dans les différentes partitions ; il ne permet pas de
+ migrer des lignes d'une partition à une autre si elles sont modifiées via
+ une commande <command>UPDATE</command>. Par contre, à la différence de
+ beaucoup de partitionnements, celui-ci permet à la table
+ <quote>parente</quote> de contenir des lignes.
+</para>
-<para> On peut remarquer quelques points intéressants :</para>
+<para>
+ On peut remarquer quelques points intéressants :
+</para>
<itemizedlist>
-<listitem><para> Chaque table de partition doit être ajoutée à la réplication individuellement. </para> </listitem>
-<listitem><para> &slony1; n'est pas conscient des relations entre les tables de partition; il les considère comme
- une série de tables indépendantes. </para> </listitem>
+
+ <listitem>
+ <para>
+ Chaque table de partition doit être ajoutée à la réplication individuellement.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ &slony1; n'est pas conscient des relations entre les tables de
+ partition ; il les considère comme une série de tables
+ indépendantes.
+ </para>
+ </listitem>
+
</itemizedlist>
+<sect2>
+<title>Support de l'ajout dynamique de partition</title>
-<sect2><title> Support de l'ajout dynamique de partition</title>
+<para>
+ Un <quote>cas d'utilisation</quote> fréquent de la réplication consiste à
+ partitionner de larges ensembles de données selon un critère temporel :
+ la semaine, le mois, le trimestre ou l'année, ce qui implique par conséquent
+ l'ajout périodique d'une nouvelle partition.
+</para>
-<para> Un <quote>cas d'utilisation</quote> fréquent de la réplication consiste
- à partitionner de large ensemble de données selon un critère temporel : la semaine,
- le moins, le trimestre ou l'année, ce qui implique par conséquent l'ajout périodique
- d'une nouvelle partition. </para>
+<para>
+ L'approche traditionnelle pour effectuer cela avec &slony1; est la
+ suivante :
+</para>
-<para> L'approche traditionnelle pour effectuer cela avec &slony1; est la suivante : </para>
+<itemizedlist>
-<itemizedlist>
-<listitem><para> <xref linkend="stmtddlscript"/> pour ajouter la nouvelle table de partition sur chaque noeud</para> </listitem>
-<listitem><para> <xref linkend="stmtcreateset"/> pour créer un ensemble de réplication temporaire </para> </listitem>
-<listitem><para> <xref linkend="stmtsetaddtable"/> pour ajouter la table dans cet ensemble </para> </listitem>
-<listitem><para> <xref linkend="stmtsubscribeset"/>, une fois pour chaque noeud abonné, afin de mettre en place
- la réplication sur chaque noeud </para> </listitem>
-<listitem><para> <xref linkend="stmtmergeset"/>, une fois que la réplication fonctionne, afin de supprimer
- l'ensemble de réplication temporaire </para> </listitem>
+ <listitem>
+ <para>
+ <xref linkend="stmtddlscript"/> pour ajouter la nouvelle table de
+ partition sur chaque nœud ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <xref linkend="stmtcreateset"/> pour créer un ensemble de réplication
+ temporaire ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <xref linkend="stmtsetaddtable"/> pour ajouter la table dans cet
+ ensemble ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <xref linkend="stmtsubscribeset"/>, une fois pour chaque nœud
+ abonné, afin de mettre en place la réplication sur chaque nœud ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <xref linkend="stmtmergeset"/>, une fois que la réplication fonctionne,
+ afin de supprimer l'ensemble de réplication temporaire
+ </para>
+ </listitem>
+
</itemizedlist>
-<para> Sachant qu'il y a de fortes chances pour que la nouvelle partition soit vide,
- il existe un mécanisme alternatif qui évite de créer un ensemble de réplication
- supplémentaire et l'utilisation de multiples requêtes <xref linkend="stmtsubscribeset"/>
- Cette alternative est la suivante : on utilise le script <xref
-linkend="stmtddlscript"/>, pour effectuer le script DDL suivant : </para>
+<para>
+ Sachant qu'il y a de fortes chances pour que la nouvelle partition soit vide,
+ il existe un mécanisme alternatif qui évite la création d'un ensemble de
+ réplication supplémentaire et l'utilisation de multiples requêtes
+ <xref linkend="stmtsubscribeset"/>. Cette alternative est la suivante :
+ on utilise le script <xref linkend="stmtddlscript"/>, pour exécuter le
+ script DDL suivant :
+</para>
<itemizedlist>
-<listitem><para> Ajouter la nouvelle partition sur chaque noeud </para> </listitem>
-<listitem><para> Exécuter les fonction stockées pour inscrire la nouvelle partition dans l'ensemble de réplication.</para>
-<para> Sur le noeud d'origine, si la table de partitionnement contient des tuples,
- le script DDL s'arrêtera car le fait que la table soit vide est une condition qui ne
- peut pas être violée. </para>
+ <listitem>
+ <para>
+ Ajouter la nouvelle partition sur chaque nœud
+ </para>
+ </listitem>
-<para> Sur les noeuds abonnés, on peut effectuer sans danger un <command>TRUNCATE</command> sur la nouvelle table. </para>
-</listitem>
+ <listitem>
+ <para>
+ Exécuter les fonction stockées pour inscrire la nouvelle partition dans
+ l'ensemble de réplication ;
+ </para>
+
+ <para>
+ Sur le nœud d'origine, si la table de partitionnement contient des
+ données, le script DDL s'arrêtera car le fait que la table soit vide est
+ une condition qui ne peut pas être violée.
+ </para>
+
+ <para>
+ Sur les nœuds abonnés, on peut effectuer sans danger un
+ <command>TRUNCATE</command> sur la nouvelle table.
+ </para>
+ </listitem>
+
</itemizedlist>
-<para> Il existe plusieurs fonctions qui prennent en charge cela :
- L'utilisateur peut utiliser celle qu'il préfère. La <quote> fonction de
-base </quote> est <function>add_empty_table_to_replication()</function>; les
-autres disposent d'arguments supplémentaires ou différents</para>
+<para>
+ Il existe plusieurs fonctions qui prennent en charge cela. L'utilisateur
+ peut utiliser celle qu'il préfère. La <quote>fonction de base</quote> est
+ <function>add_empty_table_to_replication()</function>, les autres disposent
+ d'arguments supplémentaires ou différents.
+</para>
<itemizedlist>
-<listitem><para> <function> add_empty_table_to_replication (set_id, tab_id, nspname, tabname, idxname, comment);</function> </para>
-<para> Ceci est la fonction de <quote>base</quote>; vous devez spécifier
- l'identifiant de l'ensemble (set_id), l'identifiant de la table (tab_id),
- l'espace de nom (nspname), le nom de la table(tabname), le nom de l'index (idxname)
- et un commentaire (comment) . La table sera alors ajouté dans la réplication. </para>
+ <listitem>
+ <para>
+ <function>add_empty_table_to_replication (set_id, tab_id, nspname, tabname, idxname, comment);</function>
+ </para>
-<para> Notez que le nom d'index est optionnel; si la valeur est NULL, alors
- la fonction utilisera la clé primaire de la table, en supposant qu'il en existe une.
- La fonction échouera s'il n'existe pas de clé primaire. </para>
+ <para>
+ Ceci est la fonction de <quote>base</quote> ; vous devez spécifier
+ l'identifiant de l'ensemble (set_id), l'identifiant de la table (tab_id),
+ l'espace de nom (nspname), le nom de la table(tabname), le nom de l'index
+ (idxname) et un commentaire (comment). La table sera alors ajoutée dans
+ la réplication.
+ </para>
-</listitem>
+ <para>
+ Notez que le nom d'index est optionnel. Si la valeur est NULL, alors la
+ fonction utilisera la clé primaire de la table, en supposant qu'il en
+ existe une. La fonction échouera s'il n'existe pas de clé primaire.
+ </para>
+ </listitem>
-<listitem><para> <function> replicate_partition(tab_id, nspname, tabname, idxname, comment); </function> </para>
+ <listitem>
+ <para>
+ <function>replicate_partition(tab_id, nspname, tabname, idxname, comment);</function>
+ </para>
-<para> Si l'on sait que la table qui doit être répliquée hérite d'une table mère
- répliquée elle-aussi, alors cette fonction peut récupérer les informations sur
- l'ensemble de réplication et l'origine à partir de la table mère.
-</para>
-</listitem>
+ <para>
+ Si l'on sait que la table qui doit être répliquée hérite d'une table mère
+ répliquée elle-aussi, alors cette fonction peut récupérer les
+ informations sur l'ensemble de réplication et l'origine à partir de la
+ table mère.
+ </para>
+ </listitem>
+
</itemizedlist>
+<note>
+ <para>
+ Comme il a été remarqué précédemment, &slony1; n'est pas conscient que les
+ tables sont partitionnées. Ainsi, cette approche peut être utilisée pour
+ ajouter une table vide dans la réplication.
+ </para>
+</note>
-<note><para> Comme il a été remarqué précédemment, &slony1; n'est pas conscient
- que les tables sont partitionnées. Ainsi, cette approche peut être utilisée
- pour ajouter une table vide dans la réplication. </para> </note>
</sect2>
</sect1>
Modified: traduc/trunk/slony/plainpaths.xml
===================================================================
--- traduc/trunk/slony/plainpaths.xml 2009-01-17 18:49:02 UTC (rev 1219)
+++ traduc/trunk/slony/plainpaths.xml 2009-01-17 23:43:30 UTC (rev 1220)
@@ -4,103 +4,167 @@
par $Author$
révision $Revision$ -->
-<sect1 id="plainpaths"><title> Voies de communication &slony1;</title>
-
+<sect1 id="plainpaths">
+<title> Voies de communication &slony1;</title>
<indexterm><primary>voies de communication</primary></indexterm>
-<para> &slony1; utilise le DSNs de &postgres; dans trois contextes pour établir
- ses accès aux bases de données :
+<para>
+ &slony1; utilise le DSN de &postgres; dans trois contextes pour établir
+ ses accès aux bases de données :
-<itemizedlist>
+ <itemizedlist>
-<listitem><para> <xref linkend="admconninfo"/> - contrôle comment un script
-<xref linkend="slonik"/> accède aux différents noeuds.</para>
+ <listitem>
+ <para>
+ <xref linkend="admconninfo"/> - contrôle comment un script
+ <xref linkend="slonik"/> accède aux différents nœuds.
+ </para>
-<para> Ces connexions sont celles qui vont de votre <quote>poste d'administration</quote>
- vers tous les noeuds du cluster &slony1;.</para>
+ <para>
+ Ces connexions sont celles qui vont de votre <quote>poste
+ d'administration</quote> vers tous les nœuds du cluster &slony1;.
+ </para>
-<para> Il est <emphasis>vital</emphasis> que vous ayez des connexions depuis
- l'emplacement central où les scripts <xref linkend="slonik"/> sont exécutés
- vers chacun des noeuds du réseau. Ces connexions sont uniquement utilisées
- brièvement, pour effectuer les quelques requêtes <acronym>SQL</acronym>
- nécessaire à l'administration du cluster.</para>
+ <para>
+ Il est <emphasis>vital</emphasis> que vous ayez des connexions depuis
+ l'emplacement central où les scripts <xref linkend="slonik"/> sont
+ exécutés vers chacun des nœuds du réseau. Ces connexions sont
+ uniquement utilisées brièvement pour effectuer les quelques requêtes
+ <acronym>SQL</acronym> nécessaire à l'administration du cluster.
+ </para>
-<para> Puisque ces voies de communications sont utilisées brièvement,
- il est raisonnable de <quote>regrouper</quote> les connexions temporaires
- en utilisant un <link linkend="tunnelling">tunnel SSH
-</link>.</para></listitem>
+ <para>
+ Puisque ces voies de communications sont utilisées brièvement, il est
+ raisonnable de <quote>regrouper</quote> les connexions temporaires
+ en utilisant un <link linkend="tunnelling">tunnel SSH</link>.
+ </para>
+ </listitem>
-<listitem><para> Le paramètre DSN de &lslon; DSN. </para>
+ <listitem>
+ <para>
+ Le paramètre DSN de &lslon;.
+ </para>
-<para> Le paramètre DSN passé à chaque &lslon; indique quel voie de communication
- doit être utilisée entre le processus &lslon; et la base qu'il gère.
- </para> </listitem>
+ <para>
+ Le paramètre DSN passé à chaque &lslon; indique la voie de communication
+ à utiliser par le processus &lslon; et la base qu'il gère.
+ </para>
+ </listitem>
-<listitem><para> <xref linkend="stmtstorepath"/> - contrôle comment les
- démons &lslon; communiquent avec les noeuds distants. Ces chemins sont
- stockés dans la table <xref linkend="table.sl-path"/>.</para>
+ <listitem>
+ <para>
+ <xref linkend="stmtstorepath"/> - contrôle comment les démons &lslon;
+ communiquent avec les nœuds distants. Ces chemins sont stockés
+ dans la table <xref linkend="table.sl-path"/>.
+ </para>
-<para> Vous <emphasis>devez</emphasis> forcément avoir une voie de communication
- entre chaque noeud abonné et son fournisseur; les autres voies sont facultatives.
- et ne seront utilisées que si un chemin dans la table
- <xref linkend="table.sl-listen"/> est nécessite d'utiliser cette voie particulière.</para>
-</listitem>
+ <para>
+ Vous <emphasis>devez</emphasis> forcément avoir une voie de communication
+ entre chaque nœud abonné et son fournisseur ; les autres voies
+ sont facultatives et ne seront utilisées que si un chemin dans la table
+ <xref linkend="table.sl-listen"/> nécessite d'utiliser cette voie
+ particulière.
+ </para>
+ </listitem>
-</itemizedlist></para>
+</itemizedlist>
-<para> Normalement les distinctions et la complexité potentielle des voies de communications
- ne sont pas un problème pour les personnes qui ont un réseau simple où chaque noeud
- peut voir les autres via un ensemble d'adresses réseau <quote>global</quote>.
- En revanche, cela devient important pour celles qui ont des configurations de pare-feu
- complexes, des noeuds dans plusieurs lieux et le cas où les noeuds ne sont pas
- capable de se parler via un ensemble d'adresses réseau uniforme.</para>
+</para>
-<para> Considérons le diagramme suivant, qui décrit un ensemble de six noeuds
+<para>
+ Normalement, les distinctions et la complexité potentielle des voies de
+ communications ne sont pas un problème pour les personnes qui ont un réseau
+ simple où chaque nœud peut voir les autres via un ensemble
+ <quote>global</quote> d'adresses réseau. En revanche, cela devient important
+ pour celles qui ont des configurations de pare-feu complexes, des nœuds
+ dans plusieurs lieux et dans le cas où les nœuds ne sont pas capable de
+ se parler via un ensemble d'adresses réseau uniforme.
+</para>
-<inlinemediaobject> <imageobject> <imagedata fileref="complexenv.png"/>
-</imageobject> <textobject> <phrase> Sites multiples symétriques </phrase>
-</textobject> </inlinemediaobject></para>
+<para>
+ Considérons le diagramme suivant, qui décrit un ensemble de six
+ nœuds :
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata fileref="complexenv.png"/>
+ </imageobject>
+ <textobject>
+ <phrase>Sites multiples symétriques</phrase>
+ </textobject>
+ </inlinemediaobject>
+</para>
+
<itemizedlist>
-<listitem><para> DB1 et DB2 sont des bases de données situées dans une
- <quote>zone de base de données</quote> sécurisée, protégée de l'extérieur
- par un pare-feu à l'exception d'adresses spécifiquement contrôlées.</para>
+ <listitem>
+ <para>
+ DB1 et DB2 sont des bases de données situées dans une <quote>zone de
+ base de données</quote> sécurisée, protégée de l'extérieur par un
+ pare-feu à l'exception d'adresses spécifiquement contrôlées.
+ </para>
-<para> Supposons que DB1 soit le noeud d'origine du système de réplication.</para></listitem>
+ <para>
+ Supposons que DB1 soit le nœud d'origine du système de réplication.
+ </para>
+ </listitem>
-<listitem><para> DB3 se situe dans une <quote>DMZ</quote> du même site;
-elle est considérée comme un <quote>fournisseur</quote> &slony1; pour les noeuds distants.
-</para></listitem>
-<listitem><para> DB4 est la contrepartie de DB3 dans une <quote>DMZ</quote>
-au sein du second site (site de reprise en cas de panne). Son rôle dans cette configuration
-est de <quote>nourrir</quote> les serveurs de la zone de base de données sécurisée du second site.
-</para></listitem>
-<listitem><para> DB5 et DB6 sont les équivalents de DB1 et DB2, mais sont dans ce cas
- configurés comme des noeuds abonnés.</para>
+ <listitem>
+ <para>
+ DB3 se situe dans une <quote>DMZ</quote> du même site ; elle est
+ considérée comme un <quote>fournisseur</quote> &slony1; pour les
+ nœuds distants.
+ </para>
+ </listitem>
-<para> En supposant qu'un désastre se produise sur le site <quote>primaire</quote>,
- le second site sera parfaitement équipé pour reprendre le service des applications
- qui utilise les données.</para>
+ <listitem>
+ <para>
+ DB4 est la contrepartie de DB3 dans une <quote>DMZ</quote> au sein du
+ second site (site de reprise en cas de panne). Son rôle dans cette
+ configuration est de <quote>nourrir</quote> les serveurs de la zone de
+ base de données sécurisée du second site.
+ </para>
+ </listitem>
-<para> Les directeurs qui paient les factures sont souvent retissants
- à laisser les machines du second site n'être que de simples <quote>sauvegarde</quote>;
- ils préfèrent souvent les utiliser, ce qui est tout à fait possible.
- Si le site primaire est utilisé pour les <quote>activités transactionelles</quote>,
- les répliques du site secondaires peuvent être utilisée pour produire des rapports
- qui ne nécessite pas de données synchronisées à la seconde près.</para></listitem>
+ <listitem>
+ <para>
+ DB5 et DB6 sont les équivalents de DB1 et DB2, mais sont dans ce cas
+ configurés comme des nœuds abonnés.
+ </para>
-<listitem><para> La symétrie de cette configuration signifie que si vous
- avez <emphasis>deux</emphasis> applications transactionelles nécessitant un
- protection contre les pannes, il est plus rapide d'avoir de ensemble de réplication
- supplémentaire afin que chaque site soit le site <quote>primaire</quote> d'une
- application, et que la destruction d'un site soit compensée par la consolidation
- des services sur le site restant.</para></listitem>
+ <para>
+ En supposant qu'un désastre se produise sur le site <quote>primaire</quote>,
+ le site secondaire sera parfaitement équipé pour reprendre le service des
+ applications qui utilise les données.
+ </para>
+ <para>
+ Les directeurs qui paient les factures sont souvent réfractaires à
+ laisser les machines du second site n'être que de simples
+ <quote>sauvegarde</quote> ; ils préfèrent souvent les utiliser, ce
+ qui est tout à fait possible. Si le site primaire est utilisé pour les
+ <quote>activités transactionelles</quote>, les répliques du site
+ secondaires peuvent être utilisée pour produire des rapports qui ne
+ nécessitent pas de données synchronisées à la seconde près.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ La symétrie de cette configuration signifie que si vous avez
+ <emphasis>deux</emphasis> applications transactionelles nécessitant une
+ protection contre les pannes, il est plus rapide d'avoir un ensemble de
+ réplication supplémentaire afin que chaque site soit le site
+ <quote>primaire</quote> d'une application, et que la destruction d'un
+ site soit compensée par la consolidation des services sur le site
+ restant.
+ </para>
+ </listitem>
+
</itemizedlist>
-<para></para>
+<para>
+ On pourrait également parler ici de tunnels SSH...
+</para>
-<para> On pourrait également parler ici de tunnels SSH....</para>
-
</sect1>
Modified: traduc/trunk/slony/releasechecklist.xml
===================================================================
--- traduc/trunk/slony/releasechecklist.xml 2009-01-17 18:49:02 UTC (rev 1219)
+++ traduc/trunk/slony/releasechecklist.xml 2009-01-17 23:43:30 UTC (rev 1220)
@@ -4,154 +4,281 @@
par $Author$
révision $Revision$ -->
-<sect1 id="releasechecklist"> <title>Liste de vérification pour chaque version</title>
-
+<sect1 id="releasechecklist">
+<title>Liste de vérifications pour chaque version</title>
<indexterm><primary>Liste de vérifications pour chaque version</primary></indexterm>
-<para> Voici les choses qui devraient être faites avant la sortie de chaque version :</para>
+<para>
+ Voici les choses qui devraient être faites avant la sortie de chaque
+ version :
+</para>
+
<itemizedlist>
-<listitem><para>Compilez avec succès sur chaque plate-forme supportée -
-bien que cela soit moins nécessaire lorsque l'on publie une version mineure.
- </para></listitem>
+ <listitem>
+ <para>
+ Compilez avec succès sur chaque plate-forme supportée - bien que cela
+ soit moins nécessaire lorsque l'on publie une version mineure.
+ </para>
+ </listitem>
-<listitem><para>Rédigez Un sorte de Plan de Test Standard</para></listitem>
+ <listitem>
+ <para>
+ Rédigez Un sorte de plan de test standard.
+ </para>
+ </listitem>
-<listitem><para> Si la version a modifié un ensemble de fichiers SQL spécifiques
- à une version dans <filename>src/backend</filename> ( par exemple :
- si elle ajoute un nouveau fichier <filename>slony1_base.v83.sql</filename> ou
-<filename>slony1_funcs.v83.sql</filename>), ou si nous avons d'autres changement
-dans la gestion du support des versions de &postgres;, la fonction
-<function>load_Slony_functions() </function> dans
-<filename>src/slonik/slonik.c</filename> doit être revue pour refléter
-le changement.</para> </listitem>
+ <listitem>
+ <para>
+ Si la version a modifié un ensemble de fichiers SQL spécifiques à une
+ version dans <filename>src/backend</filename> (par exemple si elle
+ ajoute un nouveau fichier <filename>slony1_base.v83.sql</filename> ou
+ <filename>slony1_funcs.v83.sql</filename>) ou si nous avons d'autres
+ changements dans la gestion du support des versions de &postgres;, la
+ fonction <function>load_Slony_functions()</function> dans
+ <filename>src/slonik/slonik.c</filename> doit être revue pour refléter
+ le changement.
+ </para>
+ </listitem>
-<listitem><para> La nouvelle version doit être ajoutée dans la fonction
-<function>upgradeSchema(text)</function> situé dans
-<filename>src/backend/slony1_funcs.sql</filename>. </para>
+ <listitem>
+ <para>
+ La nouvelle version doit être ajoutée dans la fonction
+ <function>upgradeSchema(text)</function> située dans
+ <filename>src/backend/slony1_funcs.sql</filename>.
+ </para>
-<para> Cela s'applique de manière <quote>transversale à toutes les branches</quote>;
-si nous ajoutons une version 1.1.9 dans la branche 1.1, alors la version 1.1.9 doit
-être ajoutées dans la branche 1.2 ainsi que dans les branches ultérieures ( par exemple :
-1.3, 1.4, HEAD). Normalement les branches postérieures n'ont pas besoin d'être consciente
-des versions ajoutées dans les branches ultérieures...</para> </listitem>
+ <para>
+ Cela s'applique de manière <quote>transversale à toutes les
+ branches</quote> ; si nous ajoutons une version 1.1.9 dans la
+ branche 1.1, alors la version 1.1.9 doit être ajoutée dans la branche
+ 1.2 ainsi que dans les branches ultérieures (par exemple, 1.3, 1.4,
+ HEAD). Normalement, les branches postérieures n'ont pas besoin d'être
+ conscientes des versions ajoutées dans les branches ultérieures...
+ </para>
+ </listitem>
-<listitem><para>Paquets RPM binaires</para></listitem>
+ <listitem>
+ <para>Paquets RPM binaires</para>
+ </listitem>
-<listitem> <para>Si la version est une <quote>.0</quote>, nous devons ouvrir une
- nouvelle branche STABLE.</para>
+ <listitem>
+ <para>
+ Si la version est une <quote>.0</quote>, nous devons ouvrir une
+ nouvelle branche STABLE.
+ </para>
-<para> <command> cvs tag -b REL_1_2_STABLE</command></para> </listitem>
+ <para>
+ <command>cvs tag -b REL_1_2_STABLE</command>
+ </para>
+ </listitem>
-<listitem> <para>Tagguez la branche avec l'identifiant de la version. Pour la version 1.1.2, cela donnerait
- <envar>REL_1_1_2 </envar></para>
+ <listitem>
+ <para>
+ Tagguez la branche avec l'identifiant de la version. Pour la version
+ 1.1.2, cela donnerait <envar>REL_1_1_2 </envar>.
+ </para>
-<para> <command> cvs tag REL_1_1_2 </command></para> </listitem>
+ <para>
+ <command>cvs tag REL_1_1_2 </command>
+ </para>
+ </listitem>
-<listitem><para>Récupérez une copie via <command>cvs export -rREL_1_1_2
-</command> </para></listitem>
+ <listitem>
+ <para>
+ Récupérez une copie via <command>cvs export -rREL_1_1_2</command>
+ </para>
+ </listitem>
-<listitem><para>Exécutez <application>autoconf</application> pour régénérer le fichier
-<filename>configure</filename> à partir de
-<filename>configure.ac</filename></para></listitem>
+ <listitem>
+ <para>
+ Exécutez <application>autoconf</application> pour régénérer le fichier
+ <filename>configure</filename> à partir de
+ <filename>configure.ac</filename>.
+ </para>
+ </listitem>
-<listitem><para>Purgez le répertoire <filename>autom4te.cache</filename> afin qu'il ne soit pas inclus
- dans la compilation</para>
-<para> Il n'est pas nécessaire de le faire à la main - la commande suivante <command> make distclean </command>
- le fait pour vous. </para>
-</listitem>
+ <listitem>
+ <para>
+ Purgez le répertoire <filename>autom4te.cache</filename> afin qu'il ne
+ soit pas inclus dans la compilation.
+ </para>
-<listitem><para>Purgez les fichiers .cvsignore; cela peut se faire avec la commande
- <command> find . -name .cvsignore | xargs rm </command> </para>
-<para> Il n'est pas nécessaire de le faire à la main - la commande suivante <command> make distclean </command>
- le fait pour vous. </para></listitem>
+ <para>
+ Il n'est pas nécessaire de le faire à la main - la commande suivante
+ <command>make distclean</command> le fait pour vous.
+ </para>
+ </listitem>
-<listitem><para> Exécutez <filename>tools/release_checklist.sh</filename> </para>
+ <listitem>
+ <para>
+ Purgez les fichiers .cvsignore ; cela peut se faire avec la commande
+ <command>find . -name .cvsignore | xargs rm</command>
+ </para>
-<para> Cela effectue une série de test de cohérence pour s'assurer
- que les différents fichiers qui sont supposés contenir les numéros de versions
- contiennent des valeurs cohérentes.</para>
-</listitem>
-<listitem><para>Par exemple, le fichier configure doit contenir pour la version 1.1.2:</para></listitem>
+ <para>
+ Il n'est pas nécessaire de le faire à la main - la commande suivante
+ <command>make distclean</command> le fait pour vous.
+ </para>
+ </listitem>
-<listitem><para>PACKAGE_VERSION=REL_1_1_2</para></listitem>
+ <listitem>
+ <para>
+ Exécutez <filename>tools/release_checklist.sh</filename>
+ </para>
-<listitem><para>PACKAGE_STRING=postgresql-slony1-engine REL_1_1_2</para></listitem>
+ <para>
+ Cela effectue une série de test de cohérence pour s'assurer que les
+ différents fichiers qui sont supposés contenir les numéros de versions
+ contiennent des valeurs cohérentes.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Par exemple, le fichier configure doit contenir pour la version 1.1.2 :
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>PACKAGE_VERSION=REL_1_1_2</para>
+ </listitem>
+
+ <listitem>
+ <para>PACKAGE_STRING=postgresql-slony1-engine REL_1_1_2</para>
+ </listitem>
+
</itemizedlist>
+
<itemizedlist>
-<listitem><para> <filename> config.h.in </filename> doit contenir le numéro de version
- sous deux formes; les définitions de
-<envar>SLONY_I_VERSION_STRING</envar> et
-<envar>SLONY_I_VERSION_STRING_DEC</envar> doivent être mises à jour. </para> </listitem>
+ <listitem>
+ <para>
+ <filename>config.h.in</filename> doit contenir le numéro de version sous
+ deux formes ; les définitions de <envar>SLONY_I_VERSION_STRING</envar>
+ et <envar>SLONY_I_VERSION_STRING_DEC</envar> doivent être mises à jour.
+ </para>
+ </listitem>
-<listitem><para> <filename>src/backend/slony1_funcs.sql</filename> a les numéros de version
- de majeure/mineure/patch dans les fonctions
-<function>slonyVersionMajor()</function>,
-<function>slonyVersionMinor()</function>, et
-<function>slonyVersionPatchlevel()</function>. Jusqu'à maintenant, cela doit être
-modifié <quote>à la main</quote>.</para> </listitem>
+ <listitem>
+ <para>
+ <filename>src/backend/slony1_funcs.sql</filename> a les numéros de version
+ majeure/mineure/patch dans les fonctions
+ <function>slonyVersionMajor()</function>,
+ <function>slonyVersionMinor()</function> et
+ <function>slonyVersionPatchlevel()</function>. Jusqu'à maintenant, cela
+ doit être modifié <quote>à la main</quote>.
+ </para>
+ </listitem>
-<listitem><para> Bien sûr il serait agréable si une partie de ces opérations
- pouvaient être effectuées automatiquement, d'une façon ou d'une autre.</para>
+ <listitem>
+ <para>
+ Bien sûr, il serait agréable si une partie de ces opérations pouvaient
+ être effectuées automatiquement, d'une façon ou d'une autre.
+ </para>
-<para><emphasis>Ne lancez pas</emphasis> la commande <command>commit</command> sur
- le nouveau fichier <filename>configure</filename>; nous ne devons pas
- déposer ce fichier dans le CVS.
-</para></listitem>
+ <para>
+ <emphasis>Ne lancez pas</emphasis> la commande <command>commit</command>
+ sur le nouveau fichier <filename>configure</filename> ; nous ne
+ devons pas déposer ce fichier dans le CVS.
+ </para>
+ </listitem>
-<listitem><para>Assurez-vous que les fichiers générés à partir des .l and .y sont bien créés
- , par exemple <filename>slony/conf-file.[ch]</filename> </para>
+ <listitem>
+ <para>
+ Assurez-vous que les fichiers générés à partir des .l and .y sont bien
+ créés, par exemple <filename>slony/conf-file.[ch]</filename>.
+ </para>
-<para>Pour le moment, la meilleure solution pour le faire consiste à exécuter <command> ./configure &&
-make all && make clean</command> mais c'est une approche quelque peu disgracieuse.
+ <para>
+ Pour le moment, la meilleure solution pour le faire consiste à exécuter
+ <command> ./configure && make all && make clean</command>
+ mais c'est une approche quelque peu disgracieuse.
+ </para>
-</para>
-<para> Un méthode légère meilleur consiste à lancer <command> ./configure && make
-src/slon/conf-file.c src/slonik/parser.c src/slonik/scan.c </command>
-</para>
+ <para>
+ Une méthode légèrement meilleure consiste à lancer
+ <command>./configure && make src/slon/conf-file.c
+ src/slonik/parser.c src/slonik/scan.c</command>
+ </para>
+ </listitem>
-</listitem>
+ <listitem>
+ <para>
+ Assurez-vous que les Makefiles et autres fichiers générés lors des étapes
+ précédentes ont été supprimés.
+ </para>
-<listitem><para> Assurez-vous que les Makefiles et autres fichiers générés lors des étapes
- précédentes ont été supprimés.</para>
+ <para>
+ <command>make distclean</command> le fera pour vous...
+ </para>
-<para> <command>make distclean</command> le fera pour vous... </para>
+ <para>
+ Notez que <command>make distclean</command> nettoie aussi les fichiers
+ <filename>.cvsignore</filename> et <filename>autom4te.cache</filename>,
+ rendant ainsi obsolète les étapes précédentes qui suggéraient de les
+ supprimer.
+ </para>
+ </listitem>
-<para> Notez que <command>make distclean</command> nettoie aussi les fichiers
- <filename>.cvsignore</filename> et
-<filename>autom4te.cache</filename>, rendant ainsi obsolète les étapes précédantes
-qui suggéraient de les supprimer. </para>
-</listitem>
+ <listitem>
+ <para>
+ Générez une archive tar HTML et RTF/PDF, si possible... Notez que la
+ version HTML devrait inclure les fichiers *.html (étonnant, non ?),
+ *.jpg, *.png, ainsi que *.css
+ </para>
+ </listitem>
-<listitem><para>Générez une archive tarball HTML, et RTF/PDF, si
-possible... Notez que la version HTML devrait inclure les fichiers *.html (étonnant, non?),
-*.jpg, *.png, ainsi que *.css </para></listitem>
+ <listitem>
+ <para>
+ Exécutez <command>make clean</command> dans le répertoire
+ <filename>doc/adminguide</filename> avant de générer l'archive tar afin
+ que <filename>bookindex.sgml</filename> ne fasse PAS partie de l'archive
+ tar
+ </para>
+ </listitem>
-<listitem><para>Exécutez <command>make clean</command> dans le répertoire
-<filename>doc/adminguide</filename> avant de générer le tarball afin que
-<filename>bookindex.sgml</filename> ne fasse PAS partie du tarball </para></listitem>
+ <listitem>
+ <para>
+ Alternativement, vous pouvez supprimer directement le fichier
+ <filename>doc/adminguide/bookindex.sgml</filename>.
+ </para>
+ </listitem>
-<listitem><para>Alternativement, vous pouvez supprimer directement le fichier
-<filename>doc/adminguide/bookindex.sgml </filename> </para></listitem>
+ <listitem>
+ <para>
+ Renommez le répertoire (<emphasis>par exemple</emphasis> -
+ <filename>slony1-engine</filename>) avec un nom basé sur la version,
+ <emphasis>par exemple</emphasis> - <filename>slony1-1.1.2</filename>
+ </para>
+ </listitem>
-<listitem><para>Renommez le répertoire (<emphasis>par exemple</emphasis> -
-<filename>slony1-engine</filename>) avec un nom basé sur la version,
-<emphasis>par exemple</emphasis> - <filename>slony1-1.1.2</filename>
-</para></listitem>
+ <listitem>
+ <para>
+ Générez une archive tar -
+ <command>tar tfvj slony1-1.1.2.tar.bz2 slony1-1.1.2 </command>
+ </para>
+ </listitem>
-<listitem><para>Générez un tarball - <command>tar tfvj
-slony1-1.1.2.tar.bz2 slony1-1.1.2 </command> </para></listitem>
+ <listitem>
+ <para>
+ Compilez la documentation d'administration, et construisez une archive
+ tar nommée <filename>slony1-1.1.2-html.tar.bz2</filename>.
+ </para>
-<listitem><para>Compilez la documentation d'administration, et construisez un
- tarball nommé <filename>slony1-1.1.2-html.tar.bz2</filename></para>
+ <para>
+ Assurez-vous que les documents sont à l'intérieur d'un sous-répertoire
+ d'une archive tar.
+ </para>
+ </listitem>
-<para> Assurez-vous que les documents sont à l'intérieur d'un sous-répertoire du tarball.
-</para></listitem>
+ <listitem>
+ <para>
+ Placez ces archives tar dans une zone temporaire, et informez tout le
+ monde qu'il faut les tester aussitôt que possible en suivant le plan de
+ test standard.
+ </para>
+ </listitem>
-<listitem><para>Placez ces tarballs dans une zone temporaire, et informez tout le monde
- qu'il faut les tester aussitôt que possible en suivant le Plan de Test Standard.
- </para></listitem>
+</itemizedlist>
-</itemizedlist>
</sect1>
Modified: traduc/trunk/slony/slony.xml
===================================================================
--- traduc/trunk/slony/slony.xml 2009-01-17 18:49:02 UTC (rev 1219)
+++ traduc/trunk/slony/slony.xml 2009-01-17 23:43:30 UTC (rev 1220)
@@ -71,7 +71,7 @@
</bookinfo>
<article id="slonyintro">
- <title>&slony1; Introduction</title>
+ <title>Introduction à &slony1;</title>
&intro;
&prerequisites;
@@ -79,16 +79,18 @@
&concepts;
&cluster;
&defineset;
+
</article>
&reference;
<article id="slonyadmin">
- <title> Administration Slony-I</title>
+ <title>Administration Slony-I</title>
<articleinfo>
<corpauthor>The PostgreSQL Global Development Group</corpauthor>
<author> <firstname>Christopher</firstname> <surname>Browne</surname> </author>
</articleinfo>
+
&bestpractices;
&firstdb;
&startslons;
@@ -116,6 +118,7 @@
&help;
&supportedplatforms;
&releasechecklist;
+
</article>
<article id="faq">
@@ -124,22 +127,30 @@
<corpauthor>The Slony Global Development Group</corpauthor>
<author><firstname>Christopher </firstname><surname>Browne</surname></author>
</articleinfo>
- <para> Ces questions ne sont pas toutes, au sens strict, des questions <quote>fréquemment posées</quote>;
- certaines illustrent des <emphasis>problèmes identifiés qu'il semble bon de documenter</emphasis>.</para>
+ <para>
+ Ces questions ne sont pas toutes, au sens strict, des questions
+ <quote>fréquemment posées</quote> ; certaines illustrent des
+ <emphasis>problèmes identifiés qu'il semble bon de documenter</emphasis>.
+ </para>
+
&faq;
+
</article>
-<part id="commandreference">
- <title>Le Coeur de &slony1;</title>
- &slon;
- &slonconf;
- &slonik;
- &slonikref;
-</part>
-&schemadoc;
-<!-- &bookindex; -->
+ <part id="commandreference">
+ <title>Le Cœur de &slony1;</title>
-&frenchtranslation;
+ &slon;
+ &slonconf;
+ &slonik;
+ &slonikref;
+ </part>
+
+ &schemadoc;
+ <!-- &bookindex; -->
+
+ &frenchtranslation;
+
</book>
Modified: traduc/trunk/slony/startslons.xml
===================================================================
--- traduc/trunk/slony/startslons.xml 2009-01-17 18:49:02 UTC (rev 1219)
+++ traduc/trunk/slony/startslons.xml 2009-01-17 23:43:30 UTC (rev 1220)
@@ -5,109 +5,137 @@
révision $Revision$ -->
<sect1 id="slonstart"> <title>Les démons Slon</title>
-
<indexterm><primary>exécuter le démon slon</primary></indexterm>
-<para>Les programmes qui effectuent concrètement la réplication &slony1; sont les démons
-<application>slon</application>.</para>
+<para>
+ Les programmes qui effectuent concrètement la réplication &slony1; sont les
+ démons <application>slon</application>.
+</para>
-<para>Vous devez lancer une instance <xref linkend="slon"/> sur chaque noeud
- du cluster &slony1; que ce noeud soit considéré comme maître ou esclave.
- Sous &windows;, l'exécution en tant que service est légèrement différente.
- Un service slon est installé, et un fichier de configuration est enregistré
- pour chaque noeud qui devra être servi par la machine. Le service principal
- gère alors lui-même les slons individuels. Puisque qu'une commande
- <command>MOVE SET</command> ou <command>FAILOVER</command> peut modifier
- le rôle des noeuds, slon doit fonctionner pour tous les noeuds. Il n'est
- pas essentiel que ces démons soient hébergé sur un hôte particulier, mais
- quelques principes méritent d'être considérés :
+<para>
+ Vous devez lancer une instance <xref linkend="slon"/> sur chaque nœud
+ du cluster &slony1;, que ce nœud soit considéré comme un maître ou
+ comme un esclave. Sous &windows;, l'exécution en tant que service est
+ légèrement différente. Un service slon est installé et un fichier de
+ configuration est enregistré pour chaque nœud qui devra être servi par
+ la machine. Le service principal gère alors lui-même les demons slons
+ individuels. Puisque qu'une commande <command>MOVE SET</command> ou
+ <command>FAILOVER</command> peut modifier le rôle des nœuds, slon doit
+ fonctionner pour tous les nœuds. Il n'est pas essentiel que ces démons
+ soient hébergé sur un hôte particulier mais quelques principes méritent
+ d'être considérés :
-<itemizedlist>
+ <itemizedlist>
-<listitem><para> Chaque démon <application>slon</application> doit être capable
- de communiquer rapidement avec la base de données dont il est le <quote>contrôleur</quote>
- Ainsi, si un cluster &slony1; s'étend sur un réseau longue distance (WAN), chaque processus
- slon doit être exécuté sur ou près de la base de données qu'il gère. Si vous
- enfreignez cette règle, aucun désastre ne s'en suivra mais la latence induite
- pour surveiller les événements sur son propre noeud, impliquera que le démon
- slon effectuera une réplication <emphasis>un peu</emphasis> moins rapide.
- </para></listitem>
+ <listitem>
+ <para>
+ Chaque démon <application>slon</application> doit être capable de
+ communiquer rapidement avec la base de données dont il est le
+ <quote>contrôleur</quote>. Ainsi, si un cluster &slony1; s'étend sur un
+ réseau longue distance (WAN), chaque processus slon doit être exécuté
+ sur ou près de la base de données qu'il gère. Si vous enfreignez cette
+ règle, aucun désastre ne s'en suivra mais la latence induite pour
+ surveiller les événements sur son propre nœud impliquera que le
+ démon slon effectuera une réplication <emphasis>un peu</emphasis> moins
+ rapide.
+ </para>
+ </listitem>
-<listitem><para> Les meilleurs résultats sont obtenus en exécutant
- chaque démon <application>slon</application> sur le serveur de
- base de donnée qu'il contrôle. Si il est exécuté dans un réseau
- local rapide, les performances ne seront pas dégradées de manières
- notables.</para></listitem>
+ <listitem>
+ <para>
+ Les meilleurs résultats sont obtenus en exécutant chaque démon
+ <application>slon</application> sur le serveur de base de donnée qu'il
+ contrôle. S'il est exécuté dans un réseau local rapide, les
+ performances ne seront pas dégradées de manière notable.
+ </para>
+ </listitem>
-<listitem><para> Il est intéressant de lancer plusieurs processus slon
- sur une machine unique, car il est plus simple de surveiller les
- fichiers de trace et les tables des processus lorsqu'ils se trouvent
- au même endroit. Cela évite également de devoir se connecter à
- plusieurs hôtes pour lire les fichiers de trace ou pour redémarrer
- les instances <application>slon</application>.</para></listitem>
-
-</itemizedlist>
+ <listitem>
+ <para>
+ Il est intéressant de lancer plusieurs processus slon sur une machine
+ unique car il est plus simple de surveiller les journaux applicatifs
+ et les tables des processus lorsqu'ils se trouvent au même endroit.
+ Cela évite également de devoir se connecter à plusieurs hôtes pour
+ lire les journaux applicatifs ou pour redémarrer les instances
+ <application>slon</application>.
+ </para>
+ </listitem>
+ </itemizedlist>
</para>
-<warning><para> <emphasis>Ne lancez pas</emphasis> un démon slon devant
- gérer un noeud à travers un lien WAN, si possible.
- Tout problème avec ce lien peut tuer les connexions et ainsi laisser
- des connexions <quote>zombies</quote> sur le noeud qui subsisteront
- (de manière générale) pendant environ deux heures. Ceci empêche le démarrage
- d'un autre slon, comme cela est décrit dans la <link linkend="faq"> FAQ
-</link> au sein de la section sur <link linkend="multipleslonconnections">les connexions
- slon multiples slon</link>. </para> </warning>
+<warning>
+ <para>
+ <emphasis>Ne lancez pas</emphasis> un démon slon devant gérer un nœud
+ à travers un lien WAN, si possible. Tout problème avec ce lien peut tuer
+ les connexions et ainsi laisser des connexions <quote>zombies</quote> sur
+ les nœuds qui subsisteront (de manière générale) pendant environ deux
+ heures. Ceci empêche le démarrage d'un autre slon, comme cela est décrit
+ dans la <link linkend="faq">FAQ</link> au sein de la section sur les <link
+ linkend="multipleslonconnections">connexions slon multiples</link>.
+ </para>
+</warning>
+<para>
+ Historiquement, les processus <application>slon</application> ont été plutôt
+ fragiles, défaillant dès qu'ils rencontraient une erreur significative. Ce
+ comportement impliquait l'utilisation de <quote>chiens de garde</quote> qui
+ surveillent les démons afin de s'assurer que, si un
+ <application>slon</application> s'arrête, il soit remplacé par un autre.
+</para>
-<para> Historiquement, les processus <application>slon</application>
- ont été plutôt fragiles, défaillant dès qu'ils rencontraient une
- erreur significative. Ce comportement impliquait l'utilisation de
- <quote>chiens de garde</quote> qui surveille les démons afin
- de s'assurer que si un <application>slon</application> s'arrête,
- il soit remplacé par un autre. </para>
+<para>
+ Il existe deux scripts de <quote>chiens de garde</quote> actuellement
+ disponible dans l'arborescence des sources de &slony1; :
-<para>Il existe deux scripts <quote>chiens de garde</quote> actuellement
- disponible dans l'arborescence des sources de &slony1; :
+ <itemizedlist>
+ <listitem>
+ <para>
+ <filename>tools/altperl/slon_watchdog</filename> - une version
+ <quote>précoce</quote> qui contient basiquement une boucle autour de
+ l'invocation de <xref linkend="slon"/>, redémarrant le démon à chaque
+ fois qu'il s'arrête.
+ </para>
+ </listitem>
-<itemizedlist>
+ <listitem>
+ <para>
+ <filename>tools/altperl/slon_watchdog2</filename> - une version un peu
+ plus intelligente qui sonde régulièrement la base de donnée, pour
+ vérifier qu'un événement <command>SYNC</command> s'est produit
+ récemment. Nous avons connu des connexions VPN qui se terminaient
+ parfois sans avertir l'application. Dans ce cas, le démon <xref
+ linkend="slon"/> s'arrête mais ne meurt pas. Ce mécanisme de sondage
+ résout ce problème.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
-<listitem><para> <filename>tools/altperl/slon_watchdog</filename> -
-une version <quote>précoce</quote> qui contient basiquement une boucle
-autour de l'invocation de <xref linkend="slon"/>, redémarrant à chaque
-fois que le démon s'arrête.</para>
-</listitem>
+<para>
+ Le script <filename>slon_watchdog2</filename> est <emphasis>en
+ général</emphasis> la solution préférable. Il existe un cas où elle n'est
+ pas souhaitable : lorsqu'on abonne un très gros ensemble qui nécessite
+ plusieurs heures de <command>COPY SET</command> (le principal événement que
+ provoque la requête <command>SUBSCRIBE SET</command>). Le problème qui surgit
+ dans ce cas est que le chien de garde constate qu'aucun événement
+ <command>SYNC</command> n'a été produit depuis deux heures, et déduit que
+ quelque chose est cassé, ce qui implique un redémarrage du démon slon, ce qui
+ relance du coup le <command>COPY SET</command>. Récemment, le script a été
+ modifié pour détecter les <command>COPY SET</command> en cours d'exécution.
+</para>
-<listitem><para> <filename>tools/altperl/slon_watchdog2</filename>
-- une version un peu plus intelligente qui sonde régulièrement la
-base de donnée, pour vérifier qu'un événement <command>SYNC</command>
-s'est produit récemment. Nous avons connu des connexions VPN qui se
-terminaient parfois sans avertir l'application, dans ce cas le
-démon <xref linkend="slon"/> s'arrête mais ne meurt pas; Ce mécanisme
-de sondage résout ce problème.</para></listitem>
+<para>
+ Dans &slony1; version 1.2, la structure du démon <application>slon</application>
+ a été révisée de manière importante pour le rendre moins fragile. Le processus
+ principal ne s'arrête que si vous envoyez expressément un signal lui demandant
+ de s'arrêter.
+</para>
-</itemizedlist></para>
+<para>
+ Une nouvelle approche est possible dans le script <xref
+ linkend="launchclusters"/> en utilisant les fichiers de configuration
+ <application>slon</application> et peut être invoqué comme un service dans
+ le processus de démarrage du système.
+</para>
-<para>Le script <filename>slon_watchdog2</filename> est
- <emphasis>en général</emphasis> la solution la plus préférable.
- Il existe un cas ou elle n'est pas préférable : lorsque l'on
- abonne un très gros ensemble qui nécessitera plusieurs heures
- de <command>COPY SET</command> (le principal événement que provoque
- la requête <command>SUBSCRIBE SET</command>). Le problème qui surgit
- dans ce cas est que le chien de garde constate qu'aucun événement <command>SYNC</command>
- n'a été produit depuis 2 heures, et déduit que quelque
- est cassé, ce qui implique un redémarrage du démon slon, ce qui redémarre
- également le <command>COPY SET</command>.
- Récemment le script a été modifié pour détecter les <command>COPY SET</command>
- en cours d'exécution.</para>
-
-<para>Dans &slony1; version 1.2, la structure du démon
-<application>slon</application> a été révisée de manière importante
-pour le rendre moins fragile. Le processus principal ne s'arrête que si vous envoyez
-expressément un signal lui demandant de s'arrêter. </para>
-
-<para> Une nouvelle approche est disponible dans le script <xref
-linkend="launchclusters"/> qui utilise les fichiers de configuration
-<application>slon</application> et peut être invoqué comme un service dans
-le processus de démarrage du système.</para>
-
</sect1>
Modified: traduc/trunk/slony/subscribenodes.xml
===================================================================
--- traduc/trunk/slony/subscribenodes.xml 2009-01-17 18:49:02 UTC (rev 1219)
+++ traduc/trunk/slony/subscribenodes.xml 2009-01-17 23:43:30 UTC (rev 1220)
@@ -4,16 +4,24 @@
par $Author$
révision $Revision$ -->
-<sect1 id="subscribenodes"> <title>Enregistrement des serveurs</title>
+<sect1 id="subscribenodes">
+<title>Enregistrement des serveurs</title>
+<indexterm><primary>Enregistrement des serveurs</primary></indexterm>
-<indexterm><primary>>Enregistrement des serveurs</primary></indexterm>
+<para>
+ Avant d'enregistrer un serveur à un ensemble, assurez-vous d'avoir un
+ processus <xref linkend="slon"/> pour chacune des deux parties à savoir le
+ fournisseur et pour le nouveau nœud de souscription. Si les démons slon
+ respectifs ne sont pas en cours d'exécution, alors il ne se passera rien et
+ vous vous éverturez à comprendre pourquoi cela ne fonctionne pas.
+</para>
-<para>Avant d'enregistrer un serveur à un ensemble, assurez-vous d'avoir
-<xref linkend="slon"/> un processus pour chacun des deux parties à savoir le fournisseur et pour le nouveau noeud de souscription. Si les slons respectifs ne sont pas encours d'exécution, alors il ne se passera rien, et vous battrez votre tête contre un mur essayant de comprendre pourquoi.</para>
+<para>
+ Ajouter un serveur à un ensemble de serveurs est fait en exécutant la commande
+ <xref linkend="stmtsubscribeset"/> de <xref linkend="slonik"/> . Il peut
+ sembler tentant d'essayer de souscrire plusieurs nœuds à un ensemble
+ dans un bloc d'essai simple comme celui-ci :
-<para>Enregistrer un serveur à un jeux de serveurs est fait en publiant la <xref
-linkend="slonik"/> commande <xref linkend="stmtsubscribeset"/>. Il peut sembler tentant d'essayer de souscrire plusieurs noeuds à un ensemble dans un bloc simple d'essai comme ceci :
-
<programlisting>
try {
echo 'Subscribing sets';
@@ -24,84 +32,128 @@
echo 'Enregistrement du jeu des serveurs : impossible!';
exit -1;
}
-</programlisting></para>
+</programlisting>
+</para>
+<para>
+ Mais vous êtes juste en train de vous demander quel est le souci en
+ enregistrant les ensembles de serveurs de cette façon. La méthode
+ appropriée exige de procéder à l'enregistrement des serveurs, à raison
+ d'un seul à la fois, tout en examinant le journal de l'instance de la
+ base de donnée, avant de vous occuper du prochain enregistrement. Il est
+ également intéressant de noter que le <quote>succès</quote> dans l'essai
+ <xref linkend="slonik"/> ci-dessus, n'implique pas que les nœuds 2,
+ 3, et 4 soient tous enregistrés avec succès. Il indique simplement que les
+ commandes de slonik ont été reçues avec succès le démon
+ <application>slon</application> fonctionnant sur le nœud d'origine.
+</para>
-<para> Mais vous êtes juste en train de vous demander quel est le souci en enregistrant les jeux des serveurs de cette façon. La méthode appropriée exige de procéder à l'enregistrement des serveurs, à raison d'un seul à la fois, tout en examinant le journal de l'instance de la base de donnée et avant d'entamer le prochain enregistrement. Il est également intéressant de noter que le
-<quote>succès</quote> dans le ci-dessus <xref linkend="slonik"/> essai
-de bloc, n'implique pas que les noeuds 2, 3, et 4 soient tous enregistrés avec succès. Il indique simplement que les commandes de slonik ont été avec succès reçues par <application>slon</application> fonctionnant
-sur le noeud d'origine.</para>
+<para>
+ Un cas typique de problème pouvant surgir est qu'un abonné en cascade,
+ recherche un fournisseur qui n'est pas encore prêt. Dans ce cas d'échec, le
+ nœud souscripteur ne deviendra <emphasis>jamais</emphasis> l'abonné.
+ Il sera <quote>bloquée</quote> en attente d'un évènement déjà survenu.
+ Les autres nœuds seront persuadés que, ce nœud bloqué s'est
+ enregistré correctement (parce qu'aucune erreur ne leur est parvenu) ;
+ la demande pour désabonner le nœud sera <quote>bloqué</quote> car le
+ nœud en question est coincé en attente d'enregistrement.
+</para>
-<para>Un cas typique de problème qui peut surgir est qu'un abonné en cascade, recherche un fournisseur qui n'est pas encore prêt.
-Dans ce cas d'échec, le noeud souscripteur ne deviendra <emphasis>jamais</emphasis>
-l'abonné. Il obtiendra une attente <quote>bloquée</quote> pour que l'évènement attendu
-survienne. Les autres noeuds seront persuadés que, ce noeud bloqué, s'est enregistré correctement (parce que aucune erreur ne leur remonte); la demande de désabonner le noeud sera <quote>bloqué</quote> car le noeud en question est coincé en attente d'enregistrement.</para>
+<para>
+ Lorsque vous enregistrez un nœud à un ensemble de nœuds, vous
+ devez voir quelque chose de ce genre dans les traces du démon
+ <application>slon</application> pour le nœud fournisseur :
-<para>Lorsque vous enregistrez un noeud à un jeu de noeuds, vous devriez voir quelque chose de ce genre dans les logs de <application>slon</application> pour le noeud fournisseur:
-
<screen>
DEBUG2 remoteWorkerThread_3: Received event 3,1059 SUBSCRIBE_SET
</screen>
</para>
-<para> Vous devriez également commencer à voir des entrées de notation comme ceci dans les notations de
-<application>slon</application> pour le noeud de souscription:
+<para>
+ Vous devriez également commencer à voir des messages de ce genre dans les
+ traces du démon <application>slon</application> pour le nœud de
+ souscription :
+
<screen>
DEBUG2 remoteWorkerThread_1: copy table public.my_table
</screen>
</para>
-<para>Il peut prendre un certain temps, pour de plus grandes tables, d'être copié du noeud de fournisseur au nouvel abonné. Si vous vérifiez la table de pg_stat_activity sur le noeud de fournisseur, vous devriez voir une requête qui copie la table vers stdout.
+
+<para>
+ La copie de grandes tables entre le nœud de fournisseur et le nouvel
+ abonné peut prendre un certain temps. Si vous vérifiez la table
+ pg_stat_activity sur le nœud du fournisseur, vous devriez voir une
+ requête qui copie la table vers stdout.
</para>
-<para>La table <envar>sl_subscribe</envar> pour le fournisseur comme pour le nouveau souscripteur,devra contenir un enregistrement pour le nouveau abonnement:
+<para>
+ La table <envar>sl_subscribe</envar> pour le fournisseur comme pour le
+ nouveau souscripteur, doit contenir un enregistrement pour le nouveau
+ abonnement :
+
<screen>
sub_set | sub_provider | sub_receiver | sub_forward | sub_active
---------+--------------+--------------+-------------+------------
1 | 1 | 2 | t | t
</screen>
</para>
-<para>Un ultime test est d'insérer un enregistrement dans une des tables répliquées depuis le noeud d'origine, et de vérifier que cet enregistrement se copie bien chez le souscripteur.
+
+<para>
+ Un ultime test est d'insérer un enregistrement dans une des tables répliquées
+ depuis le nœud d'origine, et de vérifier que cet enregistrement est bien
+ répliqué chez le souscripteur.
</para>
-<warning> <para> Si vous créez et souscrivez à un jeu de noeud qui ne contient aucune table, cela peut mener à une situation qui empêchera la réplication de se faire. </para>
+<warning>
+ <para>
+ Si vous créez et souscrivez à un ensemble de nœud qui ne contient
+ aucune table, cela peut mener à une situation qui empêchera la réplication
+ de se faire.
+ </para>
-<para> Notez que ce bug est notifié comme &slony1; 1.1.5 </para>
+ <para>
+ Notez que ce bug est corrigé depuis la version 1.1.5.
+ </para>
-<para> Si un abonné particulier est seulement alimenté par une séquence d'ordre d'un de ces fournisseurs, la requête qui collecte
-l'évènement<command>SYNC</command> ne sera pas correctement crée, et vous pouvez voir une erreur similaire à la suivante :
-</para>
-<screen>
-2007-04-13 07:11:28 PDT ERROR remoteWorkerThread_11: "declare LOG
+ <para>
+ Si un abonné particulier est seulement alimenté par une séquence d'ordre
+ d'un de ces fournisseurs, la requête qui collecte l'évènement
+ <command>SYNC</command> ne sera pas correctement créée, et vous pouvez
+ voir une erreur similaire celle-ci :
+ </para>
+
+ <screen>2007-04-13 07:11:28 PDT ERROR remoteWorkerThread_11: "declare LOG
cursor for select log_origin, log_xid, log_tableid, log_actionseq,
log_cmdtype, log_cmddata from "_T1".sl_log_1 where log_origin = 11 and
( order by log_actionseq; " PGRES_FATAL_ERROR ERROR: syntax error at
-or near "order" at character 162
-</screen>
+or near "order" at character 162</screen>
-<para> La fonction <xref
-linkend="function.subscribeset-integer-integer-integer-boolean"/> va générer
-un avertissement si un jeu de réplication donné, ne connais pas des quelquonc tables à répliquer, comme l'exemple suivant le montre.
-</para>
+ <para>
+ La fonction <xref
+ linkend="function.subscribeset-integer-integer-integer-boolean"/> va
+ générer un avertissement si un ensemble de réplication donné ne contient
+ aucune table à répliquer, comme l'exemple suivant le montre :
+ </para>
-<screen>
-cbbrowne at dba2:/tmp> cat create_empty_set.slonik
+ <screen>cbbrowne at dba2:/tmp> cat create_empty_set.slonik
cluster name = T1;
node 11 admin conninfo = 'dbname=slony_test1';
node 22 admin conninfo = 'dbname=slony_test2';
create set (id = 255, origin = 11, comment='blank empty set');
-subscribe set (id=255, provider = 11, receiver = 22, forward = false);
-</screen>
+subscribe set (id=255, provider = 11, receiver = 22, forward = false);</screen>
-<para> Ceci mène au message d'avertissement suivant : </para>
+ <para>
+ Ceci mène au message d'avertissement suivant :
+ </para>
-<screen>
-bbrowne at dba2:/tmp> slonik create_empty_set.slonik
+ <screen>bbrowne at dba2:/tmp> slonik create_empty_set.slonik
create_empty_set.slonik:6: NOTICE: subscribeSet:: set 255 has no tables
- risk of problems - see bug 1226
create_empty_set.slonik:6: NOTICE:
http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226
-cbbrowne at dba2:/tmp>
-</screen>
+cbbrowne at dba2:/tmp></screen>
+
</warning>
+
</sect1>
Modified: traduc/trunk/slony/supportedplatforms.xml
===================================================================
--- traduc/trunk/slony/supportedplatforms.xml 2009-01-17 18:49:02 UTC (rev 1219)
+++ traduc/trunk/slony/supportedplatforms.xml 2009-01-17 23:43:30 UTC (rev 1220)
@@ -6,19 +6,22 @@
<sect1 id="supportedplatforms">
<title>Plate-formes supportées par &slony1;</title>
-
<indexterm><primary>Plateformes supportées</primary></indexterm>
<para>
-Lefonctionnement de &slony1; a été vérifié sur les plate-formes listée ci-dessous.
-&slony1; peut être compilé, installé et éxécuté avec succès sur ces plate-formes.
+ Lefonctionnement de &slony1; a été vérifié sur les plate-formes listée
+ ci-dessous. &slony1; peut être compilé, installé et éxécuté avec succès
+ sur ces plate-formes.
</para>
-<para> Dernière mise à jour : 23 juin 2005</para>
+<para>Dernière mise à jour : 23 juin 2005</para>
-<para>Si vous rencontrez des problèmes sur une de ces plate-formes, s'il vous plait inscrivez-vous
-à la <ulink url="http://gborg.PostgreSQL.org/mailman/listinfo/slony1-general">liste de diffusion Slony-I</ulink>
-et posez vos questions.</para>
+<para>
+ Si vous rencontrez des problèmes sur une de ces plate-formes, s'il-vous-plait,
+ inscrivez-vous à la <ulink
+ url="http://gborg.PostgreSQL.org/mailman/listinfo/slony1-general">liste de
+ discussions Slony-I</ulink> et posez vos questions.
+</para>
<table id="platform-table">
<title>Plate-formes supportées</title>
@@ -35,14 +38,14 @@
</row>
</thead>
- <tbody>
+ <tbody>
<row>
<entry>Fedora Core</entry>
<entry>3</entry>
<entry>Intel - 32 bit</entry>
<entry>22 juin 2005</entry>
<entry>dvdm AROBASE truteq.co.za</entry>
- <entry>&postgres; Version: 7.4.6</entry>
+ <entry>&postgres; version 7.4.6</entry>
</row>
<row>
@@ -51,7 +54,7 @@
<entry>x86</entry>
<entry>22 juin 2005</entry>
<entry>dvdm AROBASE truteq.co.za</entry>
- <entry>&postgres; Version: 7.4.5</entry>
+ <entry>&postgres; version 7.4.5</entry>
</row>
<row>
@@ -60,7 +63,7 @@
<entry>x86</entry>
<entry>22 juin 2005</entry>
<entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; Version: 7.4.8</entry>
+ <entry>&postgres; version 7.4.8</entry>
</row>
<row>
@@ -69,7 +72,7 @@
<entry>x86</entry>
<entry>22 juin 2005</entry>
<entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; Version: 8.0.2</entry>
+ <entry>&postgres; version 8.0.2</entry>
</row>
<row>
@@ -78,7 +81,7 @@
<entry>x86</entry>
<entry>22 juin 2005</entry>
<entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; Version: 7.3.9</entry>
+ <entry>&postgres; version 7.3.9</entry>
</row>
<row>
@@ -87,7 +90,7 @@
<entry>PPC</entry>
<entry>22 juin 2005</entry>
<entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; Version: 7.4.8</entry>
+ <entry>&postgres; version 7.4.8</entry>
</row>
<row>
@@ -96,7 +99,7 @@
<entry>x86</entry>
<entry>22 juin 2005</entry>
<entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; Version: 7.4.8</entry>
+ <entry>&postgres; version 7.4.8</entry>
</row>
<row>
@@ -105,7 +108,9 @@
<entry>x86</entry>
<entry>22 juin 2005</entry>
<entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; Version: 8.0.3 , les docs ne compilent pas, la valeur de NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou alors il faut utiliser les RPM de la communauté</entry>
+ <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
+ NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
+ alors il faut utiliser les RPM de la communauté</entry>
</row>
<row>
@@ -114,7 +119,9 @@
<entry>x86</entry>
<entry>22 juin 2005</entry>
<entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; Version: 8.0.3 , les docs ne compilent pas, la valeur de NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou alors il faut utiliser les RPM de la communauté</entry>
+ <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
+ NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
+ alors il faut utiliser les RPM de la communauté</entry>
</row>
<row>
@@ -123,7 +130,9 @@
<entry>x86</entry>
<entry>22 juin 2005</entry>
<entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; Version: 8.0.3 , les docs ne compilent pas, la valeur de NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou alors il faut utiliser les RPM de la communauté</entry>
+ <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
+ NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
+ alors il faut utiliser les RPM de la communauté</entry>
</row>
<row>
@@ -132,7 +141,9 @@
<entry>x86</entry>
<entry>22 juin 2005</entry>
<entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; Version: 8.0.3 ,les docs ne compilent pas, la valeur de NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou alors il faut utiliser les RPM de la communauté</entry>
+ <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
+ NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
+ alors il faut utiliser les RPM de la communauté</entry>
</row>
<row>
@@ -141,7 +152,9 @@
<entry>x86</entry>
<entry>14 juillet 2005</entry>
<entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; Version: 8.0.3 , les docs ne compilent pas, la valeur de NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou alors il faut utiliser les RPM de la communauté</entry>
+ <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
+ NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
+ alors il faut utiliser les RPM de la communauté</entry>
</row>
<row>
@@ -150,7 +163,7 @@
<entry>AMD64</entry>
<entry>1er juillet 2005</entry>
<entry>stefan AROBASE kaltenbrunner.cc </entry>
- <entry>&postgres; Version: 8.0.3</entry>
+ <entry>&postgres; version 8.0.3</entry>
</row>
<row>
@@ -159,26 +172,29 @@
<entry>Sparc64</entry>
<entry>1er juillet 2005</entry>
<entry>stefan AROBASE kaltenbrunner.cc </entry>
- <entry>&postgres; Version: 8.0.3</entry>
+ <entry>&postgres; version 8.0.3</entry>
</row>
+
<row>
<entry>OpenBSD</entry>
<entry>3.7</entry>
<entry>x86</entry>
<entry>1er juillet 2005</entry>
<entry>stefan AROBASE kaltenbrunner.cc </entry>
- <entry>&postgres; Version: 8.0.3</entry>
+ <entry>&postgres; version 8.0.3</entry>
</row>
+
<row>
<entry><trademark>Windows</trademark></entry>
<entry>2000/XP/2003</entry>
<entry>x86</entry>
<entry>21 septembre 2006</entry>
<entry>dpage AROBASE postgresql.org </entry>
- <entry>&postgres; Version: 8.1, 8.2</entry>
+ <entry>&postgres; version 8.1, 8.2</entry>
</row>
- </tbody>
+ </tbody>
</tgroup>
</table>
+
</sect1>
Modified: traduc/trunk/slony/versionupgrade.xml
===================================================================
--- traduc/trunk/slony/versionupgrade.xml 2009-01-17 18:49:02 UTC (rev 1219)
+++ traduc/trunk/slony/versionupgrade.xml 2009-01-17 23:43:30 UTC (rev 1220)
@@ -4,91 +4,212 @@
par $Author$
révision $Revision$ -->
-<sect1 id="versionupgrade"><title>Utiliser &slony1; pour les mises à jour &postgres;</title>
-
+<sect1 id="versionupgrade">
+<title>Utiliser &slony1; pour les mises à jour &postgres;</title>
<indexterm><primary>Mettre à jour la version de &postgres; en utilisant &slony1;</primary></indexterm>
-<para> Un certain nombre de personnes ont trouvé que &slony1; était pratique pour effectuer les mises à jours de versions majeures ( <emphasis>par exemple</emphasis> celles qui nécessitent d'éxécuter <application>initdb</application> afin de recréer une nouvelle instance ) sans subir une coupure de service importante.
+<para>
+ Un certain nombre de personnes ont trouvé que &slony1; était pratique pour
+ effectuer les mises à jours de versions majeures (<emphasis>par
+ exemple</emphasis> celles qui nécessitent d'éxécuter
+ <application>initdb</application> afin de recréer une nouvelle instance)
+ sans subir une coupure de service importante.
</para>
-<para>La méthode simple que l'on peut imaginer pour effectuer une telle mise à jour consiste à éxecuter <application>pg_dump</application> sur l'ancienne version de la base, puis d'envoyer le résultat dans une session <application>psql</application> connectée à la nouvelle version de la base. Malheureusement le temps nécessaire pour cette approche peut être prohibitif. Pour une base contenant 40Go de données ainsi que de nombreux index, le processus nécessite les étapes suivantes :
-<itemizedlist>
-<listitem><para> Arrêtez toutes les applications qui peuvent modifier les données; </para></listitem>
-<listitem><para> Lancez le <application>pg_dump</application>, et charger les données dans la nouvelle base;</para></listitem>
-<listitem><para> Attendez 40 heures que le processus d'extraction/chargement se termine;</para></listitem>
-<listitem><para> Faites pointer les applications <quote>en écriture</quote> vers la nouvelle base</para></listitem>
-</itemizedlist>
+<para>
+ La méthode simple que l'on peut imaginer pour effectuer une telle mise à jour
+ consiste à exécuter <application>pg_dump</application> sur l'ancienne version
+ de la base, puis d'envoyer le résultat dans une session
+ <application>psql</application> connectée à la nouvelle version de la base.
+ Malheureusement, le temps nécessaire pour cette approche peut être prohibitif.
+ Pour une base contenant 40 Go de données ainsi que de nombreux index, le
+ processus nécessite les étapes suivantes :
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Arrêtez toutes les applications qui peuvent modifier les données ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Lancez <application>pg_dump</application> et chargez les données dans
+ la nouvelle base ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Attendez 40 heures que le processus d'extraction/chargement se
+ termine ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Faites pointer les applications <quote>en écriture</quote> vers la
+ nouvelle base.
+ </para>
+ </listitem>
+ </itemizedlist>
</para>
-<para>Notez que cette opération a provoqué une coupure de service de 40 heures.</para>
+<para>
+ Notez que cette opération a provoqué une coupure de service de 40 heures.
+</para>
-<para> &slony1; offre une opportunité de remplacer cette longue coupure de service par une autre de quelques minutes, voire quelques secondes. Cette approche consiste à créer un réplicat &slony1; utilisant la nouvelle version de &postgres;. Il est possible que cela prenne plus de 40 heures pour créer ce réplicat, mais une fois qu'il est créé, il peut être rafraîchi rapidement.
+<para>
+ &slony1; offre une opportunité de remplacer cette longue coupure de service
+ par une autre de quelques minutes, voire quelques secondes. Cette approche
+ consiste à créer un réplicat &slony1; utilisant la nouvelle version de
+ &postgres;. Il est possible que cela prenne plus de 40 heures pour créer ce
+ réplicat mais, une fois qu'il est créé, il peut être rafraîchi rapidement.
</para>
-<para> Au moment de basculer vers la nouvelle base de données, la procédure est beaucoup moins longue :
+<para>
+ Au moment de basculer vers la nouvelle base de données, la procédure est
+ beaucoup moins longue :
-<itemizedlist>
-<listitem><para> Arrêtez toutes les applications qui peuvent modifier les données;</para></listitem>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Arrêtez toutes les applications qui peuvent modifier les
+ données ;
+ </para>
+ </listitem>
-<listitem><para> Verrouillez le set contre les lectures des applications clientes en utilisant <xref linkend="stmtlockset"/>;</para></listitem>
+ <listitem>
+ <para>
+ Verrouillez le set contre les lectures des applications clientes en
+ utilisant <xref linkend="stmtlockset"/> ;
+ </para>
+ </listitem>
-<listitem><para> Lancez le commande Slonik <xref
-linkend="stmtmoveset"/> pour déplacer l'origine de l'ensemble de réplication depuis l'ancienne base vers la nouvelle.</para></listitem>
+ <listitem>
+ <para>
+ Lancez le commande Slonik <xref linkend="stmtmoveset"/> pour déplacer
+ l'origine de l'ensemble de réplication depuis l'ancienne base vers la
+ nouvelle ;
+ </para>
+ </listitem>
-<listitem><para> Faites pointer les applications vers la nouvelle base;</para></listitem>
+ <listitem>
+ <para>
+ Faites pointer les applications vers la nouvelle base.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
-</itemizedlist></para>
-
-<para> Cette procédure devrait prendre un temps très court, qui dépendra principalement de votre rapidité lors de la reconfiguration de vos applications. Si vous pouvez souhaiter automatiser toutes ces étapes, il est possible que cela prenne moins d'une seconde. Sinon il est probable que cela prenne entre quelques secondes et quelques minutes.
+<para>
+ Cette procédure devrait prendre un temps très court, qui dépendra
+ principalement de votre rapidité lors de la reconfiguration de vos
+ applications. Si vous pouvez souhaiter automatiser toutes ces étapes, il
+ est possible que cela prenne moins d'une seconde. Sinon il est probable
+ que cela prenne entre quelques secondes et quelques minutes.
</para>
-<para>Notez qu'après le déplacement de l'origine, les mises à jour vont vers l'<emphasis>ancienne</emphasis> base. Si vous découvrez qu'à cause d'un problème imprévu ou non-testé, votre application rencontre certains problèmes pour se connecter à la nouvelle base, vous pouvez facilement utiliser <xref linkend="stmtmoveset"/> à nouveau pour re-déplacer l'origine vers l'ancienne base.
+<para>
+ Notez qu'après le déplacement de l'origine, les mises à jour vont vers
+ l'<emphasis>ancienne</emphasis> base. Si vous découvrez qu'à cause d'un
+ problème imprévu ou non testé, votre application rencontre certains problèmes
+ pour se connecter à la nouvelle base, vous pouvez facilement utiliser
+ <xref linkend="stmtmoveset"/> à nouveau pour déplacer de nouveau l'origine
+ vers l'ancienne base.
</para>
-<para>Si vous considerez qu'il est particulièrement vital de pouvoir revenir à l'ancienne base dans l'état où elle se trouvait avant la bascule, afin de pouvoir revenir complètement en arrière et que vous souhaitez également pouvoir revenir à l'ancienne version (mise à jour depuis la bascule), accomplissez les étapes suivantes :
+<para>
+ Si vous considérez qu'il est particulièrement vital de pouvoir revenir à
+ l'ancienne base dans l'état où elle se trouvait avant la bascule, afin de
+ pouvoir revenir complètement en arrière et que vous souhaitez également
+ pouvoir revenir à l'ancienne version (mise à jour depuis la bascule),
+ accomplissez les étapes suivantes :
-<itemizedlist>
+ <itemizedlist>
-<listitem><para> Préparez <emphasis> deux </emphasis> réplicats &slony1; de la base;
-<itemizedlist>
-<listitem><para> Un pour la nouvelle version de &postgres;;</para></listitem>
-<listitem><para> Un pour l'ancienne version de &postgres;.</para></listitem>
-</itemizedlist></para>
+ <listitem>
+ <para>
+ Préparez <emphasis> deux </emphasis> réplicats &slony1; de la base :
+ <itemizedlist>
+ <listitem>
+ <para>Un pour la nouvelle version de &postgres; ;</para>
+ </listitem>
+ <listitem>
+ <para>Un pour l'ancienne version de &postgres;.</para>
+ </listitem>
+ </itemizedlist>
+ </para>
-<para>Ainsi vous avez <emphasis>trois</emphasis> noeuds, un avec la nouvelle versin de &postgres;, et deux autres avec l'ancienne version.</para></listitem>
+ <para>
+ Ainsi, vous avez <emphasis>trois</emphasis> nœuds, un avec la
+ nouvelle version de &postgres;, et deux autres avec l'ancienne version.
+ </para>
+ </listitem>
-<listitem><para> Une fois qu'ils sont à peu près <quote>synchronisés</quote>, arrêtez toutes les applications qui peuvent modifier les données.
-</para></listitem>
+ <listitem>
+ <para>
+ Une fois qu'ils sont à peu près <quote>synchronisés</quote>, arrêtez
+ toutes les applications qui peuvent modifier les données.
+ </para>
+ </listitem>
-<listitem><para> Lancez la synchronisation des noeuds, puis
-<command>arrêtez</command> le démon <application>slon</application> qui a synchronisé le noeud esclave qui héberge l'ancienne version de &postgres;
-</para>
+ <listitem>
+ <para>
+ Lancez la synchronisation des nœuds, puis
+ <command>arrêtez</command> le démon <application>slon</application>
+ qui a synchronisé le nœud esclave qui héberge l'ancienne version
+ de &postgres;.
+ </para>
-<para>Vous voudrez peut-être utiliser <xref linkend="stmtuninstallnode"/> pour
-isoler ce noeud et ainsi le transformer en une base indépendante, ou simplement tuer le démon <application>slon</application>, selon
-votre volonté de rendre cette transformation permanente ou non.
-</para></listitem>
+ <para>
+ Vous voudrez peut-être utiliser <xref linkend="stmtuninstallnode"/>
+ pour isoler ce nœud et ainsi le transformer en une base
+ indépendante, ou simplement tuer le démon
+ <application>slon</application>, selon votre volonté de rendre cette
+ transformation permanente ou non.
+ </para>
+ </listitem>
-<listitem><para> Ensuite utilisez <xref linkend="stmtmoveset"/> pour déplacer l'origine, comme décrit précédemment.</para></listitem>
+ <listitem>
+ <para>
+ Ensuite utilisez <xref linkend="stmtmoveset"/> pour déplacer l'origine,
+ comme décrit précédemment.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
-</itemizedlist></para>
+<para>
+ Si de <quote>petits</quote> problèmes apparaissent, vous pourrez récupérer
+ le nœud qui héberge l'ancienne base qui a reçu les mises à jours de
+ données. Si vous découvrez des problèmes plus importants, vous pouvez
+ abandonner les deux nœuds et revenir à la base qui a été isolée.
+</para>
-<para> Si de <quote>petits</quote> problèmes apparaissent, vous pourrez récupérer
- le noeud qui héberge l'ancienne base qui a reçues les mises à jours de données;
- Si vous découvrez des problèmes plus importants, vous pouvez abandonner les deux noeuds
- et revenir à la base qui a été isolée.</para>
+<para>
+ Il ne s'agit pas ici de dire qu'il est courant de rencontrer des problèmes
+ qui nécessitent une procédure aussi <quote>paranoïaque</quote>. Toutefois,
+ les personnes soucieuses d'évaluer les risques peuvent être rassurées par de
+ tels choix.
+</para>
-<para>Il ne s'agit pas ici de dire qu'il est courant
- de rencontrer des problèmes qui nécessitent une procédure aussi <quote>paranoïaque</quote>;
- Toutefois les personnes soucieuses d'évaluer les risques peuvent être rassurées
- par de tels choix.
-
-<note><para>&slony1; ne supporte pas les versions de &postgres; antérieures à la 7.3.3
- parcequ'il a besoin des espaces de noms ("namespaces") qui n'étaient pas stable jusque là.
- Rod Taylor modifia une version de &slony1; pour qu'elle fonctionne avec la 7.2 en autorisant
- les objets &slony1; à se placer dans le schéma global. Il trouva cela assez compliqué, de plus
- certaines requêtes n'était pas assez rapides ( l'optimiseur de requêtes de &postgres; a été <emphasis>considérablement</emphasis> amélioré depuis la version 7.2), cependant cette solution était plus pratique pour lui que les autres systèmes de réplication tels que <productname>eRServer</productname>. Si vous recherchez désespérement ce type de solution, contactez-le sur la liste des hackers de &postgres;. Il n'est pas prévu que la version 7.2 de &postgres; soit supportée par une version officielle de &slony1;
+<note>
+ <para>
+ &slony1; ne supporte pas les versions de &postgres; antérieures à la 7.3.3
+ parce qu'il a besoin des espaces de noms (« namespaces ») qui
+ n'étaient pas stables jusque là. Rod Taylor modifia une version de &slony1;
+ pour qu'elle fonctionne avec la 7.2 en autorisant les objets &slony1; à se
+ placer dans le schéma global. Il trouva cela assez compliqué. De plus,
+ certaines requêtes n'étaient pas assez rapides (l'optimiseur de requêtes de
+ &postgres; a été <emphasis>considérablement</emphasis> amélioré depuis la
+ version 7.2), cependant cette solution était plus pratique pour lui que
+ les autres systèmes de réplication tels que
+ <productname>eRServer</productname>. Si vous recherchez désespérement ce
+ type de solution, contactez-le sur la liste des hackers de &postgres;. Il
+ n'est pas prévu que la version 7.2 de &postgres; soit supportée par une
+ version officielle de &slony1;
+ </para>
+</note>
-</para></note></para>
-
</sect1>
More information about the Trad
mailing list