[Trad] [svn:pgfr] r1244 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Lun 23 Fév 16:43:58 CET 2009
Author: gleu
Date: 2009-02-23 16:43:58 +0100 (Mon, 23 Feb 2009)
New Revision: 1244
Modified:
traduc/trunk/slony/addthings.xml
traduc/trunk/slony/adminscripts.xml
traduc/trunk/slony/bestpractices.xml
traduc/trunk/slony/defineset.xml
traduc/trunk/slony/failover.xml
traduc/trunk/slony/filelist.xml
traduc/trunk/slony/firstdb.xml
traduc/trunk/slony/installation.xml
traduc/trunk/slony/legal.xml
traduc/trunk/slony/loganalysis.xml
traduc/trunk/slony/logshipping.xml
traduc/trunk/slony/maintenance.xml
traduc/trunk/slony/monitoring.xml
traduc/trunk/slony/slon.xml
traduc/trunk/slony/slonconf.xml
traduc/trunk/slony/slonik_ref.xml
traduc/trunk/slony/slony.xml
traduc/trunk/slony/slonyupgrade.xml
traduc/trunk/slony/subscribenodes.xml
traduc/trunk/slony/supportedplatforms.xml
traduc/trunk/slony/testbed.xml
traduc/trunk/slony/usingslonik.xml
Log:
Suppression des passages sp?\195?\169cifiques ?\195?\160 Slony 2.0.0.
(je ne sais pas pourquoi, mais il y a eu un mix Slony 1.2 / Slony 2.0 dans la
doc traduite)
Modified: traduc/trunk/slony/addthings.xml
===================================================================
--- traduc/trunk/slony/addthings.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/addthings.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -336,15 +336,6 @@
pas de supprimer le schéma et son contenu, elle supprime également toutes
les colonnes ajoutées avec la commande <xref linkend= "stmttableaddkey"/>.
</para>
-
- <note>
- <para>
- Dans &slony1; version 2.0, <xref linkend="stmttableaddkey"/>
- <emphasis>n'est plus supporté</emphasis> et donc <xref
- linkend="stmtuninstallnode"/> correspond simplement à <command>DROP
- SCHEMA "nom_du_cluster" CASCADE;</command>.
- </para>
- </note>
</listitem>
</itemizedlist>
Modified: traduc/trunk/slony/adminscripts.xml
===================================================================
--- traduc/trunk/slony/adminscripts.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/adminscripts.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -1063,10 +1063,6 @@
<sect2 id="bsd-ports-profile">
<title><filename>slon.in-profiles</filename></title>
<subtitle>profiles dans le style d'Apache pour FreeBSD <filename>ports/databases/slony/*</filename></subtitle>
-<indexterm>
- <primary>profiles dans le style d'Apache pour FreeBSD</primary>
- <secondary>FreeBSD</secondary>
-</indexterm>
<para>
Dans le répertoire <filename>tools</filename>, le script
@@ -1077,118 +1073,4 @@
</sect2>
-<sect2 id="duplicate-node">
-<title><filename>duplicate-node.sh</filename></title>
-<indexterm><primary>dupliquer un nœud</primary></indexterm>
-
-<para>
- Dans le répertoire <filename>tools</filename>, le script
- <filename>duplicate-node.sh</filename> aide à créer un nouveau nœud
- en dupliquant un des nœuds du cluster.
-</para>
-
-<para>
- Ce script attend les paramètres suivants :
-</para>
-
-<itemizedlist>
- <listitem><para>le nom du cluster ;</para></listitem>
- <listitem><para>le numéro du nouveau nœud ;</para></listitem>
- <listitem><para>le nœud origine ;</para></listitem>
- <listitem><para>le nœud répliqué ;</para></listitem>
- <listitem><para>le nouveau nœud ;</para></listitem>
-</itemizedlist>
-
-<para>
- Pour chaque nœud spécifié, le script permet de préciser les paramètres
- de type <function>libpq</function> pour <envar>PGHOST</envar>,
- <envar>PGPORT</envar>, <envar>PGDATABASE</envar> et <envar>PGUSER</envar>. Le
- fichier <filename>.pgpass</filename> peut être utilisé pour le stockage des
- mots de passe, ce qui est généralement considéré comme une bonne pratique.
- Lorsqu'elles ne sont pas définies, ces valeurs peuvent hériter des variables
- d'environnement <function>libpq</function>, ce qui est pratique quand on
- réalise des tests. Toutefois, lorsque que ce script est utilisé <quote>de
- manière brutale</quote>, il est souvent nécessaire de définir les 14
- paramètres disponibles.
-</para>
-
-<para>
- Ce script prépare des fichiers, placés dans <filename>/tmp</filename>, et
- annonce le nom du répertoire qu'il a créé pour les scripts SQL et &lslonik;
- de configuration du nouveau nœud.
-</para>
-
-<itemizedlist>
- <listitem>
- <para><filename>schema.sql</filename></para>
- <para>
- Ce script est tiré du nœud origine et contient le schéma de données
- <quote>originel</quote> qui doit être appliqué au départ.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>slonik.preamble</filename></para>
- <para>
- Ce fichier <quote>preambule</quote> est utilisé par l'ensemble des scripts
- slonik ci-dessous.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>step1-storenode.slonik</filename></para>
- <para>
- Un script &lslonik; qui configure le nouveau nœud.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>step2-storepath.slonik</filename></para>
- <para>
- Un script &lslonik; qui met en place des voies de communication entre
- le nœud fournisseur et le nouveau nœud.
- </para>
- </listitem>
-
- <listitem>
- <para><filename>step3-subscribe-sets.slonik</filename></para>
- <para>
- Un script &lslonik; qui demande la souscription à tous les ensembles de
- réplication.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Lorsque l'on effectue un test, cela est suffisant pour faire fonctionner un
- nouveau nœud. La configuration ne doit pas forcément correspondre à une
- configuration finale, notamment :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Il est souhaitable de construire des voies de communication
- supplémentaires afin d'assurer leur redondance.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Les scripts générés supposent que le nouveau nœud doit être un
- nœud transmetteur (« forwarding »), ce qui n'est pas
- forcément vrai.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Il est parfois souhaitable, une fois que le processus d'abonnement est
- réalisé complètement, de modifier les abonnements.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
</sect1>
Modified: traduc/trunk/slony/bestpractices.xml
===================================================================
--- traduc/trunk/slony/bestpractices.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/bestpractices.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -205,21 +205,6 @@
<listitem>
<para>
- Si vous utilisez le processus autovacuum avec une version récente de
- &postgres;, vous pouvez éviter de le faire pour les tables &slony1; car
- &slony1; est un peu plus intelligent que le démon autovaccuum lorsqu'il
- s'agit des VACUUM dans des conditions de réplication (<emphasis>par
- exemple</emphasis> : la purge des anciennes données).
- </para>
-
- <para>
- Reportez-vous au chapitre <xref linkend="maintenance-autovac"/> pour plus
- de détails.
- </para>
- </listitem>
-
- <listitem>
- <para>
Il a été prouvé qu'il est préférable d'exécuter tous les démons &lslon;
sur un serveur central pour chaque sous-réseau.
</para>
@@ -329,14 +314,6 @@
clef. Ceci entraînerait potentiellement des bogues dans votre application
à cause de &slony1;.
</para>
-
- <warning>
- <para>
- Dans la version 2 de &slony1;, <xref linkend="stmttableaddkey"/> n'est
- plus supportée. Vous <emphasis>devez</emphasis> absolument avoir soit
- une vraie clef primaire, soit une clef primaire candidate.
- </para>
- </warning>
</listitem>
<listitem>
@@ -737,27 +714,27 @@
verrouiller l'accès au nœud pour tous les utilisateurs autres que
<command>slony</command> car :
</para>
-
- <itemizedlist>
- <listitem>
- <para>
- Les applications s'exécutent sur des données partiellement copiées
- qui ne seront pas cohérentes.
- </para>
- </listitem>
+ </listitem>
+</itemizedlist>
- <listitem>
- <para>
- Il est possible que certaines applications (et certains scripts de
- maintenance) soumettent une combinaison de requêtes qui placeront
- le système dans une situation d'inter-blocage
- (« deadlock »), ce qui annulera l'événement
- <command>COPY_SET</command> et impliquera le ré-abonnement complet
- du nœud.
- </para>
- </listitem>
- </itemizedlist>
+<itemizedlist>
+ <listitem>
+ <para>
+ Les applications s'exécutent sur des données partiellement copiées
+ qui ne seront pas cohérentes.
+ </para>
</listitem>
+
+ <listitem>
+ <para>
+ Il est possible que certaines applications (et certains scripts de
+ maintenance) soumettent une combinaison de requêtes qui placeront
+ le système dans une situation d'inter-blocage
+ (« deadlock »), ce qui annulera l'événement
+ <command>COPY_SET</command> et impliquera le ré-abonnement complet
+ du nœud.
+ </para>
+ </listitem>
</itemizedlist>
<para>
Modified: traduc/trunk/slony/defineset.xml
===================================================================
--- traduc/trunk/slony/defineset.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/defineset.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -108,18 +108,12 @@
<listitem>
<para>
Si la table n'a pas de clef primaire candidate, vous devez demander à
- &slony1; d'en produire une en utilisant la commande <xref
- linkend="stmttableaddkey"/>.
+ &slony1; d'en fournir une. Tout d'abord, vous devez utiliser <xref
+ linkend="stmttableaddkey"/> pour ajouter une colonne peuplée en utilisant
+ une séquence &slony1;. Ensuite, <xref linkend="stmtsetaddtable"/> inclut
+ la directive <option>key=serial</option> pour indiquer que la propre
+ colonne de &slony1; doit être utilisé.
</para>
-
- <warning>
- <para>
- La commande <xref linkend="stmttableaddkey"/> a toujours été considérée
- au mieux comme un <quote>bricolage</quote>, et à partir de la version
- 2.0, elle est considérée comme une mauvaise fonctionnalité qu'il faut
- supprimer.
- </para>
- </warning>
</listitem>
</itemizedlist>
@@ -174,18 +168,6 @@
</para>
<para>
- Un autre problème survient fréquemment lorsque l'on réplique via un
- WAN ; parfois la connexion réseau est un peu instable, si bien
- qu'il y a des risques qu'une connexion reste ouverte pendant plusieurs
- heures et entraîne un <command>CONNECTION TIMEOUT</command>. Si cela se
- produit à 95% d'une copie d'un ensemble de réplication de 50 tables,
- représentant 250GB de données, cela va gâcher votre journée. Au contraire
- si les tables sont séparées en plusieurs ensembles de réplication, cette
- panne réseau qui intervient à 95% n'interrompra que la copie
- d'<emphasis>un seul</emphasis> ensemble.
- </para>
-
- <para>
Certains <quote>effets négatifs</quote> surviennent lorsque la base de
données répliquée contient plusieurs Go de données, et qu'il faut des
heures ou des jours pour qu'un nœud abonné réalise une copie
Modified: traduc/trunk/slony/failover.xml
===================================================================
--- traduc/trunk/slony/failover.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/failover.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -60,68 +60,11 @@
<listitem>
<para>
Au moment ou nous écrivons ces lignes, basculer vers un autre serveur
- nécessite que l'application se reconnecte à la nouvelle base de donnée.
+ nécessite que l'application se reconnecte à la base de donnée.
Donc, pour éviter toute complication, nous éteignons le serveur web. Les
utilisateurs qui ont installé <application>pgpool</application> pour
gérer les connexions peuvent simplement éteindre le pool.
</para>
-
- <para>
- Les actions à mener dépendent beaucoup de la configuration des
- applications qui utilisent la base de données. En général, les
- applications qui étaient connectées à l'ancienne base doivent détruire
- leurs connexions et en établir de nouvelles vers la base qui vient d'être
- promue dans le rôle du <quote>/maître/</quote>. Il y a différentes façons
- de configurer cela, et donc différentes façon d'effectuer la bascule :
-
- <itemizedlist>
- <listitem>
- <para>
- L'application stocke le nom de la base de donnée dans un fichier.
- </para>
-
- <para>
- Dans ce cas, la reconfiguration nécessite de changer la valeur dans
- ce fichier, d'arrêter puis de relancer l'application pour qu'elle
- pointe vers le nouvel emplacement des données.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Une utilisation pertinente de DNS consiste à créer des <ulink
- url="http://www.iana.org/assignments/dns-parameters">champs DNS</ulink>
- CNAME qui permettent à l'application d'utiliser un nom pour
- référencer le nœud qui joue le rôle du nœud
- <quote>maître</quote>.
- </para>
-
- <para>
- Dans ce cas, la reconfiguration nécessite de changer le CNAME pour
- pointer vers le nouveau serveur. De plus, il faut probablement
- relancer l'application pour rafraîchir les connexions à la base.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si vous utilisez <application>pgpool</application> ou un
- <quote>gestionnaire de connexions</quote> similaire, alors la
- reconfiguration implique de modifier le paramètrage de cet outil,
- à part cela la procédure est similaire à l'exemple DNS/CNAME
- ci-dessus.
- </para>
- </listitem>
- </itemizedlist>
- </para>
-
- <para>
- La nécessité de redémarrer l'application qui se connecte à la base dépend
- de la manière dont elle a été conçue et des mécanismes de gestion d'erreurs
- de connexion qui ont été implémentés ; si à la suite d'une erreur
- elle tente d'ouvrir à nouveau une connexion, alors il n'est pas nécessaire
- de la relancer.
- </para>
</listitem>
<listitem>
@@ -309,33 +252,33 @@
de force le nœud en panne hors du réseau afin d'éviter toute confusion
au niveau des applications. Cela peut être fait via une interface SNMP qui
effectue une partie des opérations suivantes :
+</para>
- <itemizedlist>
- <listitem>
- <para>Éteindre l'alimentation du serveur en panne.</para>
+<itemizedlist>
+ <listitem>
+ <para>Éteindre l'alimentation du serveur en panne.</para>
- <para>
- Si l'on ne fait pas attention, le serveur peut réapparaître dans le
- système de réplication si un administrateur le rallume.
- </para>
- </listitem>
+ <para>
+ Si l'on ne fait pas attention, le serveur peut réapparaître dans le
+ système de réplication si un administrateur le rallume.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Modifier les règles du pare-feu ou d'autres configurations pour exclure
- du réseau l'adresse IP du serveur en panne.
- </para>
+ <listitem>
+ <para>
+ Modifier les règles du pare-feu ou d'autres configurations pour exclure
+ du réseau l'adresse IP du serveur en panne.
+ </para>
- <para>
- Si le serveur a de multiples interfaces, et donc de multiple adresses IP,
- cette approche permet de supprimer/désactiver les adresses utilisées
- par l'application, tout en conservant les adresses
- <quote>administratives</quote> afin que le serveur reste accessible par
- les administrateurs systèmes.
- </para>
- </listitem>
- </itemizedlist>
-</para>
+ <para>
+ Si le serveur a de multiples interfaces, et donc de multiple adresses IP,
+ cette approche permet de supprimer/désactiver les adresses utilisées
+ par l'application, tout en conservant les adresses
+ <quote>administratives</quote> afin que le serveur reste accessible par
+ les administrateurs systèmes.
+ </para>
+ </listitem>
+</itemizedlist>
</sect2>
Modified: traduc/trunk/slony/filelist.xml
===================================================================
--- traduc/trunk/slony/filelist.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/filelist.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -48,9 +48,7 @@
<!ENTITY loganalysis SYSTEM "loganalysis.xml">
<!ENTITY slonyupgrade SYSTEM "slonyupgrade.xml">
<!ENTITY releasechecklist SYSTEM "releasechecklist.xml">
-<!ENTITY raceconditions SYSTEM "raceconditions.xml">
<!ENTITY partitioning SYSTEM "partitioning.xml">
-<!ENTITY triggers SYSTEM "triggers.xml">
<!-- specifique PGFR -->
<!ENTITY frenchtranslation SYSTEM "frenchtranslation.xml">
Modified: traduc/trunk/slony/firstdb.xml
===================================================================
--- traduc/trunk/slony/firstdb.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/firstdb.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -127,27 +127,6 @@
pgbench -i -s 1 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME</programlisting>
<para>
- Une des tables créées par <application>pgbench</application>,
- <envar>history</envar>, n'a pas de clé primaire. Dans les versions
- antérieures de &slony1;, une commande &slonik; nommée <xref
- linkend="stmttableaddkey"/> pouvait être utilisées pour en introduire une.
- Ceci provoquait de nombreux problèmes si bien que cette fonctionnalité fut
- supprimée dans la version 2 de &slony1;. Il est désormais
- <emphasis>nécessaire</emphasis> d'avoir une ensemble éligible en tant que
- clé primaire.
-</para>
-
-<para>
- Les requêtes SQL suivantes établissent une clé primaire cohérente pour cette
- table :
-</para>
-
-<programlisting>psql -U $PGBENCH_USER -h $HOST1 -d $DBNAME1 -c "begin; alter table
-history add column id serial; update history set id =
-nextval('history_id_seq'); alter table history add primary key(id);
-commit"</programlisting>
-
-<para>
Puisque &slony1; dépend de la présence du langage procédural pl/pgSQL, nous
devons l'installer maintenant. Il est possible que vous ayez installé
pl/pgSQL dans la base template1, auquel cas vous pouvez sauter cette étape
@@ -296,7 +275,7 @@
set add table (set id=1, origin=1, id=1, fully qualified name = 'public.accounts', comment='accounts table');
set add table (set id=1, origin=1, id=2, fully qualified name = 'public.branches', comment='branches table');
set add table (set id=1, origin=1, id=3, fully qualified name = 'public.tellers', comment='tellers table');
- set add table (set id=1, origin=1, id=4, fully qualified name = 'public.history', comment='history table');
+ set add table (set id=1, origin=1, id=4, fully qualified name = 'public.history', comment='history table', key = serial);
#--
# Création du second noeud (l'esclave)
Modified: traduc/trunk/slony/installation.xml
===================================================================
--- traduc/trunk/slony/installation.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/installation.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -266,7 +266,7 @@
ce bug mais il n'y a eu aucun progrès depuis. La seconde URL ci-dessous
indique qu'il y a eu des tentatives de correction en élevant la valeur de
NAMELEN dans une future version de Red Hat Enterprise Linux, mais cela n'est
- pas le cas en 2008. La distribution Fedora Core 4 devrait avoir corrigé ce
+ pas le cas en 2005. La distribution Fedora Core 4 devrait avoir corrigé ce
problème plus tôt.
</para>
Modified: traduc/trunk/slony/legal.xml
===================================================================
--- traduc/trunk/slony/legal.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/legal.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -5,7 +5,7 @@
révision $Revision$ -->
<copyright>
- <year>2004-2007</year>
+ <year>2004-2006</year>
<holder>The PostgreSQL Global Development Group</holder>
</copyright>
@@ -13,7 +13,7 @@
<title>Notice légale</title>
<para>
- <productname>PostgreSQL</productname> est sous le Copyright &copy; 2004-2007
+ <productname>PostgreSQL</productname> est sous le Copyright &copy; 2004-2006
du PostgreSQL Global Development Group et est distribué sous les termes
de la licence de l'Université de Californie ci-dessous.
</para>
Modified: traduc/trunk/slony/loganalysis.xml
===================================================================
--- traduc/trunk/slony/loganalysis.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/loganalysis.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -35,16 +35,6 @@
</sect2>
<sect2>
-<title>Notifications INFO</title>
-
-<para>
- Les événements, qui semblent avoir un intérêt au niveau INFO et qui sont
- toujours listés, tout comme les notifications CONFIG.
-</para>
-
-</sect2>
-
-<sect2>
<title>Notifications DEBUG</title>
<para>
Modified: traduc/trunk/slony/logshipping.xml
===================================================================
--- traduc/trunk/slony/logshipping.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/logshipping.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -432,7 +432,7 @@
-- Node 11, Event 656
start transaction;
-select "_T1".setsyncTracking_offline(1, '655', '656', '2007-09-23 18:37:40.206342');
+select "_T1".setsyncTracking_offline(1, '655', '656', '2005-09-23 18:37:40.206342');
-- end of log archiving header
</programlisting>
</para>
@@ -447,7 +447,7 @@
-- Node 11, Event 109
start transaction;
-select "_T1".setsyncTracking_offline(1, '96', '109', '2007-09-23 19:01:31.267403');
+select "_T1".setsyncTracking_offline(1, '96', '109', '2005-09-23 19:01:31.267403');
-- end of log archiving header</programlisting>
</para>
@@ -525,34 +525,6 @@
</sect2>
<sect2>
-<title><application>find-triggers-to-deactivate.sh</application></title>
-<indexterm><primary>désactivation des triggers</primary></indexterm>
-
-<para>
- Le <ulink url="http://www.slony.info/bugzilla/show_bug.cgi?id=19">bug
- #19</ulink> indique que le dump d'un schéma peut contenir des triggers
- et des règles que l'on ne souhaite pas activer sur un nœud de log
- shipping.
-</para>
-
-<para>
- L'outil <filename> tools/find-triggers-to-deactivate.sh</filename> a été
- créé pour assister l'utilisateur dans cette tache. Il peut être lancé sur un
- nœud qui sera utilisé comme schéma source, et il liste les règles et
- les triggers, présents sur ce nœud, qui devraient être désactivés.
-</para>
-
-<para>
- Cela comprend le trigger <function>logtrigger</function> et
- <function>denyaccess</function> qui sont normalement exclut du schéma extrait
- avec pgdump. Il est toutefois de la responsabilité de l'administrateur de
- vérifier que des triggers comme ceux-ci sont bien retirés du réplicat du log
- shipping.
-</para>
-
-</sect2>
-
-<sect2>
<title>L'outil <application>slony_logshipper</application></title>
<para>
Modified: traduc/trunk/slony/maintenance.xml
===================================================================
--- traduc/trunk/slony/maintenance.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/maintenance.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -84,66 +84,6 @@
</itemizedlist>
</para>
-<sect2 id="maintenance-autovac">
-<title>Interaction avec l'autovacuum de &postgres;</title>
-<indexterm><primary>interaction avec autovacuum</primary></indexterm>
-
-<para>
- Les versions récentes de&postgres; proposent un processus
- <quote>autovacuum</quote> qui détecte les modifications sur les tables et
- la création de lignes mortes, puis nettoie ces tables, <quote>à la
- demande</quote>. On a constaté que cela peut interagir de manière négative
- avec la politique de VACUUM de &slony1; sur ces propres tables.
-</para>
-
-<para>
- &slony1; demande des VACUUM sur ses tables immédiatement après avoir complété
- les transactions qui sont sensées supprimer de vieilles données, ce qui est
- considéré comme le meilleur moment pour le faire. Il semble que l'autovacuum
- détecte les changements un peu trop tôt, et lance un VACUUM alors que les
- transactions ne sont pas terminées, ce qui est relativement inutile. Il
- apparaît préférable de configurer l'autovacuum pour éviter les tables de
- configuration gérées par &slony1;.
-</para>
-
-<para>
- La requête suivante identifie les tables que l'autovacuum ne doit pas traiter
- (remplacez le nom du cluster par celui de votre configuration locale) :
-</para>
-
-<programlisting>
-moncluster=# select oid, relname from pg_class where relnamespace = (select oid from pg_namespace where nspname = '_' || 'monCluster') and relhasindex;
- oid | relname
--------+--------------
- 17946 | sl_nodelock
- 17963 | sl_setsync
- 17994 | sl_trigger
- 17980 | sl_table
- 18003 | sl_sequence
- 17937 | sl_node
- 18034 | sl_listen
- 18017 | sl_path
- 18048 | sl_subscribe
- 17951 | sl_set
- 18062 | sl_event
- 18069 | sl_confirm
- 18074 | sl_seqlog
- 18078 | sl_log_1
- 18085 | sl_log_2
-(15 rows)
-</programlisting>
-
-<para>
- La requête suivante remplira la table <envar>pg_catalog.pg_autovacuum</envar>
- avec les informations de configuration adéquates :
- <command>INSERT INTO pg_catalog.pg_autovacuum (vacrelid, enabled)
- SELECT oid, 'f' FROM pg_catalog.pg_class
- WHERE relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = '_' || 'monCluster')
- AND relhasindex;</command>
-</para>
-
-</sect2>
-
<sect2><title>Chiens de garde : garder les Slons en vie</title>
<indexterm><primary>Chiens de garde pour garder en vie les démons slon</primary></indexterm>
@@ -180,7 +120,6 @@
<sect2 id="gensync"><title>En parallèle aux chiens de garde :
generate_syncs.sh</title>
-<indexterm><primary>générer des SYNC</primary></indexterm>
<para>
Un nouveau script est apparu dans &slony1; 1.1, il s'agit de
@@ -373,7 +312,6 @@
</sect2>
<sect2><title>Autres tests de réplication</title>
-<indexterm><primary>tester la réplication</primary></indexterm>
<para>
La méthodologie de la section précédente est conçu avec un vue pour minimiser
@@ -473,190 +411,4 @@
</sect2>
-<sect2><title>Service</title>
-<indexterm><primary>service pour BSD </primary></indexterm>
-
-<sect3><title>slon</title>
-
-<para>
- Ce script crée un répertoire pour le service slon qui pourra être utilisé
- avec la commande svscan de daemontools. Ce script utilise multilog de manière
- très basique, ce qui semble être standard pour les installations daemontools
- / multilog. Si vous souhaitez une gestion intelligente des journaux applicatifs,
- consultez la section logrep ci-dessous. Actuellement, ce script a des
- possibilités de gestion d'erreurs très limitées.
-</para>
-
-<para>
- Pour les usages non-interactifs, configurez les variables d'environnement
- suivantes : <envar>BASEDIR</envar>, <envar>SYSUSR</envar>,
- <envar>PASSFILE</envar>, <envar>DBUSER</envar>, <envar>HOST</envar>,
- <envar>PORT</envar>, <envar>DATABASE</envar>, <envar>CLUSTER</envar> et
- <envar>SLON_BINARY</envar>. Si une seule de ces valeurs n'est pas définie,
- le script demande les informations de manière interactive.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <envar>BASEDIR</envar>, l'emplacement où la structure du répertoire du
- service slon sera créée. Il ne faut <emphasis>pas</emphasis> que ce soit
- le répertoire <filename>/var/service</filename> ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>SYSUSR</envar>, l'utilisateur unix qui lancera le processus slon
- (et multilog) ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>PASSFILE</envar>, l'emplacement du fichier
- <filename>.pgpass</filename> (par défaut
- <filename>~sysusr/.pgpass</filename>) ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>DBUSER</envar>, l'utilisateur postgres que slon doit utiliser (par
- défaut slony) ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>HOST</envar>, l'adresse du serveur ou slon doit se connecter (par
- défaut localhost) ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>PORT</envar>, le port de connexion (par défaut 5432) ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>DATABASE</envar>, la base de données sur laquelle slon se connecte
- (par défaut dbuser)
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>CLUSTER</envar>, le nom du cluster Slony1 (par défaut database) ;
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>SLON_BINARY</envar>, le chemin complet vers le binaire slon (par
- défaut <command>which slon</command>).
- </para>
- </listitem>
-</itemizedlist>
-
-</sect3>
-
-<sect3><title>logrep-mkservice.sh</title>
-
-<para>
- Ce script utilise <command>tail -F</command> pour extraire des données des
- journaux applicatifs en vous permettant d'utiliser des filtres multilog (via
- l'option CRITERIA) afin de créer des journaux de transactions spécifiques.
- Le but est de fournir un moyen de surveiller les journaux de transactions en
- temps réel en quête de données <quote>intéressante</quote> sans devoir
- modifier le journal applicatif initial ou gacher des ressources CPU/IO
- en parcourant les journaux régulièrement.
-</para>
-
-<para>
- Pour une utilisation non interactive, il faut configurer les variables :
- <envar>BASEDIR</envar>, <envar>SYSUSR</envar>, <envar>SOURCE</envar>,
- <envar>EXTENSION</envar> et <envar>CRITERIA</envar>. Si une seule de ces
- options n'est pas définie, le script demande interactivement les informations
- de configuration.
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- <envar>BASEDIR</envar>, l'emplacement où sera créée la structure du
- répertoire du service de logrep. Il ne faut <emphasis>pas</emphasis> que
- ce soit le répertoire <filename>/var/service</filename>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>SYSUSR</envar>, l'utilisateur unix qui lancera le service.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>SOURCE</envar>, le nom du service de log que vous voulez utiliser.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>EXTENSION</envar>, une balise pour différencier ce logrep de ceux
- qui utilisent la même source.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <envar>CRITERIA</envar>, le filtre multilog que vous voulez utiliser.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Un exemple trivial consiste à produire un journal applicatif de tous les
- messages d'erreur slon qui pourraient être utilisés pour déclencher une
- alerte nagios :
- <command>EXTENSION='ERRORS'</command>
- <command>CRITERIA="'-*' '+* * ERROR*'"</command>
- (on relance la surveillance en déclenchant une rotation des journaux
- applicatifs avec <command>svc -a $svc_dir</command>)
-</para>
-
-<para>
- Une application plus intéressante est la surveillance de la progression
- d'une souscription d'un nœud :
- <command>EXTENSION='COPY'</command>
- <command>CRITERIA="'-*' '+* * ERROR*' '+* * WARN*' '+* * CONFIG enableSubscription*' '+* * DEBUG2 remoteWorkerThread_* prepare to copy table*' '+* * DEBUG2 remoteWorkerThread_* all tables for set * found on subscriber*' '+* * DEBUG2 remoteWorkerThread_* copy*' '+* * DEBUG2 remoteWorkerThread_* Begin COPY of table*' '+* * DEBUG2 remoteWorkerThread_* * bytes copied for table*' '+* * DEBUG2 remoteWorkerThread_* * seconds to*' '+* * DEBUG2 remoteWorkerThread_* set last_value of sequence*' '+* * DEBUG2 remoteWorkerThread_* copy_set*'"</command>
-</para>
-
-<para>
- Si vous avez une trace d'abonnement, alors il est facile de déterminer si un
- nœud donné est en train de réaliser une copie ou une autre activité de
- souscription. Si les journaux applicatifs ne sont pas vide et ne se terminent
- pas par <command>"CONFIG enableSubscription: sub_set:1"</command> (où 1 est
- le numéro d'ensemble de réplication que vous avez abonné) alors le slon est
- au milieu d'une copie initiale.
-</para>
-
-<para>
- Si vous surveillez l'horodatage de modification du journal applicatif de
- votre nœud primaire pour déterminer si le slon est tombé dans le coma,
- vérifier cette trace d'abonnement est un bon moyen d'éviter de stopper le
- nœud alors qu'un abonnement est en cours. En bonus, puisque les slons
- utilisent svscan, vous pouvez simplement détruire le fichier (via l'interface
- svc) et laisser svscan le recommencer plus tard. J'ai également découvert que
- les traces de COPY sont pratiques pour suivre de manière interactive
- l'activité des abonnements.
-</para>
-
-</sect3>
-
-</sect2>
-
</sect1>
Modified: traduc/trunk/slony/monitoring.xml
===================================================================
--- traduc/trunk/slony/monitoring.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/monitoring.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -316,12 +316,7 @@
Le script <filename>mkmediawiki.pl </filename>, situé dans
<filename>tools</filename>, peut être utilisé pour générer un rapport de
surveillance du cluster compatible avec le populaire logiciel <ulink
- url="http://www.mediawiki.org/">MediaWiki</ulink>. Notons que l'option
- <option>--categories</option> permet à l'utilisateur de préciser un ensemble
- de catégories (séparées par une virgule) qui seront associées aux résultats.
- Si vous avez passer l'option <option>--categories=slony1</option> à une série
- de clusters &slony1;, cela entraînera la création d'une page catégorie
- répertoriant l'ensemble des clusters &slony1;.
+ url="http://www.mediawiki.org/">MediaWiki</ulink>.
</para>
<para>
@@ -331,7 +326,7 @@
<screen>
~/logtail.en> mvs login -d mywiki.example.info -u "Chris Browne" -p `cat ~/.wikipass` -w wiki/index.php
Doing login with host: logtail and lang: en
-~/logtail.en> perl $SLONYHOME/tools/mkmediawiki.pl --host localhost --database slonyregress1 --cluster slony_regress1 --categories=Slony-I > Slony_replication.wiki
+~/logtail.en> perl $SLONYHOME/tools/mkmediawiki.pl --host localhost --database slonyregress1 --cluster slony_regress1 > Slony_replication.wiki
~/logtail.en> mvs commit -m "More sophisticated generated Slony-I cluster docs" Slony_replication.wiki
Doing commit Slony_replication.wiki with host: logtail and lang: en
</screen>
Modified: traduc/trunk/slony/slon.xml
===================================================================
--- traduc/trunk/slony/slon.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/slon.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -67,13 +67,10 @@
<para>
Les cinq premiers niveaux de débogage (de Fatal à Info) sont
- <emphasis>toujours</emphasis> affichés dans les traces. Dans les
- premières versions de &slony1;, le niveau des traces
- <quote>suggéré</quote> était 2, ce qui affichait tous les messages
- jusqu'au niveau Debug2. Avec &slony1; version 2, il est recommandé
- de positionner <envar>log_level</envar> à 0 ; la plupart des
- informations intéressantes sont produites à des niveaux supérieurs
- à celui-là.
+ <emphasis>toujours</emphasis> affichés dans les traces. Si
+ <envar>log_level</envar> est configuré à 2 (un choix routinier et,
+ généralement, préférable), alors les messages de niveaux de
+ débogage 1 et 2 seront aussi envoyés.
</para>
</listitem>
</varlistentry>
Modified: traduc/trunk/slony/slonconf.xml
===================================================================
--- traduc/trunk/slony/slonconf.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/slonconf.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -102,17 +102,11 @@
<listitem>
<para>Niveau de traces de débogage (plus la valeur est haute, plus les
messages sont verbeux).
- Valeurs possibles : de 0 à 4. Valeur par défaut : 0.</para>
+ Valeurs possibles : de 0 à 4. Valeur par défaut : 2.</para>
<para>Il y a <link linkend="nineloglevels">neuf niveaux de messages
de trace</link> ; en utilisant cette option, une partie ou l'ensemble
- des niveaux <quote>debug</quote> peut être désactivé.
- Avec &slony1; version 2, beaucoup de niveaux de message ont
- été révisé afin que des <quote>informations intéressantes</quote>
- apparaissent à partir des niveaux CONFIG/INFO, et qu'il soit possible
- de fonctionner au niveau 0, en ignorant tous les messages
- <quote>DEBUG</quote> et continuer à recevoir des informations
- utiles dans les journaux applicatifs.</para>
+ des niveaux <quote>debug</quote> peut être désactivé.</para>
</listitem>
</varlistentry>
@@ -367,37 +361,6 @@
</listitem>
</varlistentry>
- <varlistentry id="slon-config-cleanup-interval" xreflabel="slon_config_cleanup_interval">
- <term><varname>cleanup_interval</varname> (<type>interval</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>cleanup_interval</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>
- Contrôle à quelle fréquence les vieux événements doivent être effacés.
- En corollaire, cela contrôle le nettoyage des tables
- <envar>sl_log_1</envar> et <envar>sl_log_2</envar>.
- Valeur par défaut : '10 minutes'.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="slon-config-cleanup-deletelogs" xreflabel="slon_conf_cleanup_deletelogs">
- <term><varname>cleanup_deletelogs</varname> (<type>booléen</type>)
- <indexterm>
- <primary>paramètre de configuration <varname>cleanup_deletelogs</varname></primary>
- </indexterm>
- </term>
- <listitem>
- <para>
- Contrôle si la commande DELETE est utilisée (ou pas) pour effacer les anciennes données
- à l'intérieur des tables <envar>sl_log_1</envar> et <envar>sl_log_2</envar>.
- Valeur par défaut : false.
- </para>
- </listitem>
- </varlistentry>
-
<varlistentry id="slon-config-desired-sync-time" xreflabel="desired_sync_time">
<term><varname>desired_sync_time</varname> (<type>entier</type>)
<indexterm>
Modified: traduc/trunk/slony/slonik_ref.xml
===================================================================
--- traduc/trunk/slony/slonik_ref.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/slonik_ref.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -410,13 +410,6 @@
<xref linkend="stmtstorenode"/>, la différence étant que <command>INIT
CLUSTER</command> n'a pas besoin de récupérer la configuration des autres nœuds.
</para> </note>
- <note> <para>Soyez conscients que certains objets qui sont créés contiennent
- le nom du cluster à l'intérieur de leur nom (notamment, les index
- partiels sur <envar>sl_log_1</envar> et <envar>sl_log_2</envar>).
- Ceci implique que les noms de cluster <emphasis>très longs</emphasis>
- sont une mauvaise idée car ils entraînent un dépassement des noms
- d'objets au delà de la limite de 63 caractères.
- </para> </note>
</refsect1>
<refsect1> <title>Utilisation de verrous</title>
@@ -970,8 +963,7 @@
</para>
<para>
- En dernier recours, <emphasis>dans les versions de &slony1; antérieures
- à la 2.0</emphasis>, cette commande peut être utilisée pour ajouter
+ En dernier recours, cette commande peut être utilisée pour ajouter
un attribut à une table qui ne possède par de clef primaire.
Sachant que cette modification peut avoir des effets secondaires
indésirables, <emphasis>il est très fortement recommandé que les
@@ -979,12 +971,6 @@
leurs propres moyens</emphasis>.
</para>
- <para>Si vous comptez utilisez &slony1; version 2.0, vous
- <emphasis>devez</emphasis> vous débrouiller pour définir
- une clef primaire plus adéquate.
- &slony1; ne vous en fournira pas une et si vous
- avez des clefs créées via <command>TABLE ADD KEY</command>,
- ne vous attendez pas à ce que &slony1; fonctionne correctement.</para>
<variablelist>
<varlistentry><term><literal>NODE ID = ival</literal></term>
<listitem><para>Identifiant du nœud de l'ensemble de réplication d'origine
@@ -1051,16 +1037,6 @@
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
-<warning> <para>Cette commande n'est <emphasis>plus supportée</emphasis>
- à partir de &slony1; version 2.0. Dans la version 2, les différentes
- <quote>modifications du catalogue</quote> réalisée sur les
- versions de &postgres; antérieures à la 8.3 sont éliminées
- afin que les exports de schéma puissent être utilisés sur n'importe
- quel nœud. Ainsi les colonnes <quote>bricolées</quote> par
- <command>TABLE ADD KEY</command> sont la chose qui empêche la commande
- <xref linkend="stmtuninstallnode"/> d'être équivalente à
- la commande SQL <command>drop schema _nom_du_cluster
- cascade;</command>.</para> </warning>
</refsect1>
</refentry>
@@ -1775,17 +1751,6 @@
</varlistentry>
</variablelist>
</para>
- <note><para>Une astuce consiste à lancer <command>STORE
- TRIGGER</command> <emphasis>avant que le trigger ne soit installé
- </emphasis>, ce qui ne provoquera pas d'erreurs. Vous pouvez
- ainsi définir la gestion d'un trigger par &slony1;
- <emphasis>avant</emphasis> qu'il ne soit installé. Vous êtes alors
- certain que le trigger est actif sur tous les nœuds immédiatement
- après son installation via <xref linkend="stmtddlscript"/> ; il n'y a
- aucun risque de voir un événement passer entre les événements
- <command>EXECUTE SCRIPT</command> et <command>STORE TRIGGER</command>.
- </para>
- </note>
<para>Cette commande utilise &funstoretrigger;.</para>
</refsect1>
<refsect1><title>Exemple</title>
@@ -1806,9 +1771,6 @@
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
- <para>Avec &slony1; version 2.0, cette commande est supprimée car
-obsolète. En effet, les triggers ne sont plus <quote>trafiqués</quote>
-dans le catalogue système.</para>
</refsect1>
</refentry>
@@ -1874,10 +1836,6 @@
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
-
- <para>Avec &slony1; version 2.0, cette commande est supprimée car
-obsolète. En effet, les triggers ne sont plus <quote>trafiqués</quote>
-dans le catalogue système.</para>
</refsect1>
</refentry>
@@ -2532,8 +2490,8 @@
</varlistentry>
<varlistentry><term><literal>EXECUTE ONLY ON = ival</literal></term>
<listitem><para>(Optionnel) L'identifiant du seul nœud qui
-doit exécuter le script. Cette option implique que le script sera propagé
-sur tous les nœuds mais exécuté sur un seul.
+doit exécuter le script. Cette option implique que le script sera propagé, par <xref linkend="slonik"/>,
+ <emphasis>seulement</emphasis> sur le seul nœud spécifié.
Par défaut, on exécute le script sur tous les nœuds abonnés à l'ensemble de réplication.
</para></listitem>
@@ -2569,14 +2527,14 @@
<programlisting>
EXECUTE SCRIPT (
SET ID = 1,
- FILENAME = '/tmp/changes_2008-04-01.sql',
+ FILENAME = '/tmp/changes_2004-05-01.sql',
EVENT NODE = 1
);
</programlisting>
</refsect1>
<refsect1> <title>Utilisation de verrous</title>
- <para>Sur les versions antérieures à la branche 2.0, un verrou exclusif est posé
+ <para>Un verrou exclusif est posé
sur chaque table répliquée sur le nœud origine, afin de retirer les triggers
de réplication. Une fois le script DDL achevé, ces verrous sont enlevés.
</para>
@@ -2586,13 +2544,6 @@
les triggers des tables répliquées.
</para>
- <para>À partir de la branche 2.0, &slony1; utilise un GUC qui contrôle
-le comportement des triggers, ce qui permet de désactiver les triggers créés par
-&slony1; pendant l'opération <emphasis>sans</emphasis> poser de verrous exclusifs sur
-toutes les tables. Désormais, les seules tables qui sont verrouillées sont les tables
-qui sont effectivement modifiées par le script DDL.
- </para>
-
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
@@ -2934,82 +2885,5 @@
</refsect1>
</refentry>
- <refentry id ="stmtcloneprepare"><refmeta><refentrytitle>CLONE PREPARE</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>CLONE PREPARE</refname>
-
- <refpurpose>Prépare le clonage d'un nœud.</refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>clone prepare</command>
- <arg><replaceable class="parameter">id</replaceable></arg>
- <arg><replaceable class="parameter">provider</replaceable></arg>
- <arg><replaceable class="parameter">comment</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>
- Cette commande prépare le clonage d'un nœud donné.
- </para>
-
- <para>
- Ceci duplique la configuration d'un nœud <quote>fournisseur</quote>
- sous un nouvel identifiant en préparation de la copie de ce nœud
- via un outil standard.
- </para>
-
- <para>Notez que pour être certain que ce nouveau nœud est cohérent avec
-tous les nœuds, il est important de lancer un événement SYNC sur tous les
-nœuds à l'exception du fournisseur et d'attendre que tous ces événements
-SYNC soient confirmés avant de copier la base fournisseur.
-Sinon il est possible que le clone ait raté des événements.
- </para>
-
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- clone prepare (id = 33, provider = 22, comment='Clone 33');
- sync (id=11);
- sync (id=22);
- </programlisting>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.2.0.</para>
- </refsect1>
- </refentry>
- <refentry id ="stmtclonefinish"><refmeta><refentrytitle>CLONE FINISH</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
- <refnamediv><refname>CLONE FINISH</refname>
- <refpurpose>Termine le clonage d'un nœud.</refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>clone prepare</command>
- <arg><replaceable class="parameter">id</replaceable></arg>
- <arg><replaceable class="parameter">provider</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>
- Cette commande achève le clonage sur un nœud donné.
- </para>
- <para>Ceci complète le travail effectué par <xref linkend="stmtcloneprepare"/> en établissant les données de confirmation
- pour le nouveau <quote>clone</quote> à partir du statut trouvé pour le nœud <quote>fournisseur</quote>.
- </para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- clone finish (id = 33, provider = 22);
- </programlisting>
- </refsect1>
- <refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.2.0.</para>
- </refsect1>
- </refentry>
-
</reference>
Modified: traduc/trunk/slony/slony.xml
===================================================================
--- traduc/trunk/slony/slony.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/slony.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -101,9 +101,7 @@
&failover;
&listenpaths;
&plainpaths;
- &triggers;
&locking;
- &raceconditions;
&addthings;
&dropthings;
&logshipfile;
@@ -116,8 +114,6 @@
&testbed;
&loganalysis;
&help;
- &supportedplatforms;
- &releasechecklist;
</article>
@@ -148,6 +144,9 @@
</part>
+
+ &supportedplatforms;
+ &releasechecklist;
&schemadoc;
<!-- &bookindex; -->
Modified: traduc/trunk/slony/slonyupgrade.xml
===================================================================
--- traduc/trunk/slony/slonyupgrade.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/slonyupgrade.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -132,250 +132,4 @@
</varlistentry>
</variablelist>
-<sect2>
-<title>Problème avec TABLE ADD KEY dans &slony1; 2.0</title>
-
-<para>
- Généralement, les mises à jour de versions &slony1; ne nécessitent pas de
- porter une attention particulière au réplicat existant, c'est-à-dire que vous
- pouvez simplement arrêter les &slon;s, mettre en place les binaires, lancer
- <xref linkend="stmtupdatefunctions"/> sur chaque nœud et redémarrer
- &lslon;. Les modifications de schéma étant uniquement sur le schéma du cluster,
- <xref linkend="stmtupdatefunctions"/> est capable de réaliser toutes les
- altérations. Avec la version 2, cela change s'il existe des tables qui
- utilisaient <xref linkend="stmttableaddkey"/>. La version 2 ne supporte pas
- la colonne <quote>extra</quote>, et <quote>réparer</quote> le schéma pour
- obtenir une clé primaire correcte n'est pas dans les attributions de <xref
- linkend="stmtupdatefunctions"/>.
-</para>
-
-<para>
- Lorsque qu'on met à jour depuis une version 1.0.x, 1.1.x ou 1.2.x vers une
- version 2, il est nécessaire de supprimer toute clé primaire gérée par
- &slony1;.
-</para>
-
-<para>
- On peut identifier les tables concernées avec la requête SQL suivante :
-
- <command>SELECT n.nspname, c.relname FROM pg_class c,
-pg_namespace n WHERE c.oid in (SELECT attrelid FROM pg_attribute WHERE
-attname LIKE '_Slony-I_%rowID' and not attisdropped) and reltype &lt&gt 0
-and n.oid = c.relnamespace order by n.nspname, c.relname;</command>
-
-</para>
-
-<para>
- L'approche la plus simple pour rectifier l'état de ces tables est la
- suivante :
-</para>
-
-<itemizedlist>
-
- <listitem>
- <para>
- Retirer la table de la réplication avec la commande &lslonik;
- <xref linkend="stmtsetdroptable"/>
- </para>
-
- <para>
- Ceci ne supprime <emphasis>pas</emphasis> les colonnes créées par
- &slony1;.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Sur chaque nœud, exécutez un script SQL pour modifier la table et
- supprimez les colonnes additionnelles.
- </para>
-
- <para>
- <command>ALTER TABLE nom_table DROP COLUMN "_Slony-I_cluster-rowID";</command>
- </para>
-
- <para>
- Ceci doit être exécuté sur chaque nœud. Selon votre préférence,
- vous pouvez utiliser <xref linkend="stmtddlscript"/> pour cela.
- </para>
-
- <para>
- Si la table est une table massivement mise à jour, sachez que cette
- modification posera un verrou exclusif sur la table. Elle ne détiendra
- pas ce verrou très longtemps ; supprimer une colonne est une
- opération assez rapide car cela se contente de marquer la colonne comme
- supprimée. Cela ne nécessite <emphasis>pas</emphasis> de réécrire toute
- la table. Les lignes qui ont une valeur dans cette colonne continueront à
- avoir cette valeur. Pour les nouvelles lignes, la valeur sera NULL, et
- les requêtes ignoreront cette colonne. L'espace occupé par ces colonnes
- sera récupéré lorsque les lignes seront mises à jour.
- </para>
-
- <para>
- Notez qu'à cette étape de la procédure, cette table n'est pas répliquée.
- Si une erreur a lieu, la réplication à cet instant n'apporte aucune
- protection sur cette table. C'est dommage mais inévitable.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Assurez-vous que la table possède un candidat éligible pour une clé
- primaire, c'est-à-dire un ensemble de colonnes NOT NULL et UNIQUE.
- </para>
-
- <para>
- Les différents cas possibles font que les développeurs n'ont pas fait
- d'efforts pour automatiser cette procédure.
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- Si la table est petite, il peut être parfaitement raisonnable
- d'ajouter une nouvelle colonne (notez que cela doit être fait sur
- <emphasis>chaque nœud</emphasis> !), lui assigner une
- une nouvelle séquence et la déclarer comme clé primaire.
- </para>
-
- <para>
- S'il n'y a que quelques lignes, cela ne prend qu'une fraction de
- seconde et avec de la chance, cela n'aura pas d'impact sur
- l'application.
- </para>
-
- <para>
- Même si la table est relativement large, alors qu'elle n'est pas
- accédée fréquemment par l'application, alors le verrouillage de la
- table provoqué par <command>ALTER TABLE</command> n'entraînera pas
- d'inconvénients.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Si la table est large, qu'elle est vitale et fortement utilisée par
- l'application, alors il peut être nécessaire de prévoir une coupure
- de service de l'application afin d'accomplir les modifications, ce
- qui vous laissera un peu vulnérable tant que la procédure ne sera pas
- complétée.
- </para>
-
- <para>
- Si une coupure de service est problématique, alors la mise à jour
- vers &slony1; version 2 devra être planifiée avec soin...
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- Créez un nouvel ensemble de réplication (<xref linkend="stmtcreateset"/>
- et ajoutez à nouveau la table dans cet ensemble (<xref
- linkend="stmtsetaddtable"/>).
- </para>
-
- <para>
- S'il existe plusieurs tables, elles peuvent être gérées via un ensemble
- de réplication unique.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Abonnez l'ensemble de réplication (<xref linkend="stmtsubscribeset"/>)
- pour tous les nœuds désirés.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Une fois que l'abonnement est complété, fusionnez les ensembles de
- réplications si nécessaire (<xref linkend="stmtmergeset"/>).
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Cette approche devrait fonctionner pour les tables qui sont relativement
- petites ou rarement utilisées. D'autre part, si la table est large et
- massivement utilisée, une autre approche pourrait être nécessaire,
- c'est-à-dire créer votre propre séquence, et <quote>promouvoir</quote>
- l'ancienne colonne générée par &slony1; dans une colonne <quote>réelle</quote>
- au sein du schéma de votre base de données. Les grandes lignes de cette
- procédure sont les suivantes :
-</para>
-
-<itemizedlist>
- <listitem>
- <para>
- Ajouter une séquence qui assigne des valeurs à la colonne.
- </para>
-
- <para>
- Les étapes d'installation incluent les commandes SQL <command>CREATE
- SEQUENCE</command>, <command>SELECT SETVAL()</command> (pour définir
- une valeur de séquence assez haute pour refléter les valeurs utilisées
- dans la table), le <xref linkend="stmtcreateset"/> de Slonik (pour créer
- un ensemble de réplication dans lequel on placera la séquence), le
- <xref linkend="stmtsetaddsequence"/> de Slonik (pour placer la séquence
- dans l'ensemble de réplication), le <xref linkend="stmtsubscribeset"/>
- de Slonik (pour définir les abonnements de ce nouvel ensemble de
- réplication).
- </para>
- </listitem>
-
- <listitem>
- <para>
- Attachez la séquence à la colonne dans la table.
- </para>
-
- <para>
- Ceci implique les commandes <command>ALTER TABLE ALTER COLUMN</command>,
- qui doivent être exécutées via la commande Slonik <xref
- linkend="stmtddlscript"/>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Renommez la colonne <envar>_Slony-I_ at CLUSTERNAME@_rowID</envar> afin que
- &slony1; ne considère pas qu'elle est sous son contrôle.
- </para>
-
- <para>
- Ceci implique les commandes <command>ALTER TABLE ALTER COLUMN</command>,
- qui doivent être exécutées via la commande Slonik <xref
- linkend="stmtddlscript"/>.
- </para>
-
- <para>
- Notez que ces deux modifications peuvent être accomplies au sein d'une
- requête <xref linkend="stmtddlscript"/> unique.
- </para>
- </listitem>
-</itemizedlist>
-
-</sect2>
-
-<sect2>
-<title>Nouvelle gestion des triggers dans &slony1; Version 2</title>
-
-<para>
- Un des changements majeurs de &slony1; est que l'activation et la
- désactivation des triggers et règles (« rules ») se fait
- maintenant entièrement en SQL, supporté par &postgres; 8.3+, plutôt
- que via des modifications directes dans le catalogue système.
-</para>
-
-<para>
- Cela implique que les utilisateurs de &slony1; doivent étudier la syntaxe
- &postgres; pour <command>ALTER TABLE</command> car c'est ainsi qu'ils
- accompliront ce qu'ils accomplissait précédemment via les commandes <xref
- linkend="stmtstoretrigger"/> et <xref linkend="stmtdroptrigger"/>.
-</para>
-
-</sect2>
-
</sect1>
Modified: traduc/trunk/slony/subscribenodes.xml
===================================================================
--- traduc/trunk/slony/subscribenodes.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/subscribenodes.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -122,7 +122,7 @@
voir une erreur similaire celle-ci :
</para>
- <screen>2007-04-13 07:11:28 PDT ERROR remoteWorkerThread_11: "declare LOG
+ <screen>2005-04-13 07:11:28 PDT ERROR remoteWorkerThread_11: "declare LOG
cursor for select log_origin, log_xid, log_tableid, log_actionseq,
log_cmdtype, log_cmddata from "_T1".sl_log_1 where log_origin = 11 and
( order by log_actionseq; " PGRES_FATAL_ERROR ERROR: syntax error at
Modified: traduc/trunk/slony/supportedplatforms.xml
===================================================================
--- traduc/trunk/slony/supportedplatforms.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/supportedplatforms.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -14,7 +14,7 @@
sur ces plate-formes.
</para>
-<para>Dernière mise à jour : 23 juin 2005</para>
+<para>Dernière mise à jour : 17 novembre 2006</para>
<para>
Si vous rencontrez des problèmes sur une de ces plate-formes, s'il-vous-plait,
@@ -147,6 +147,33 @@
</row>
<row>
+ <entry>Fedora Core</entry>
+ <entry>5</entry>
+ <entry>x86</entry>
+ <entry>Nov 17, 2006</entry>
+ <entry>devrim at CommandPrompt.com</entry>
+ <entry>&postgres; Version: 8.1.5</entry>
+ </row>
+
+ <row>
+ <entry>Fedora Core</entry>
+ <entry>6</entry>
+ <entry>x86</entry>
+ <entry>Nov 17, 2006</entry>
+ <entry>devrim at CommandPrompt.com</entry>
+ <entry>&postgres; Version: 8.1.5</entry>
+ </row>
+
+ <row>
+ <entry>Fedora Core</entry>
+ <entry>6</entry>
+ <entry>x86_64</entry>
+ <entry>Nov 17, 2006</entry>
+ <entry>devrim at CommandPrompt.com</entry>
+ <entry>&postgres; Version: 8.1.5</entry>
+ </row>
+
+ <row>
<entry>Red Hat Linux</entry>
<entry>9</entry>
<entry>x86</entry>
Modified: traduc/trunk/slony/testbed.xml
===================================================================
--- traduc/trunk/slony/testbed.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/testbed.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -264,63 +264,6 @@
</para>
</glossdef>
</glossentry>
-
- <glossentry>
- <glossterm><envar>SLONCONF[n]</envar></glossterm>
-
- <glossdef>
- <para>
- Si cette valeur est positionnée à <quote>true</quote> pour un nœud
- donnée qui est généralement configurée dans le fichier
- <filename>settings.ik</filename> pour un test donné, alors la
- <link linkend="runtime-config">configuration</link> sera placée dans un
- un fichier de configuration <filename>slon.conf</filename> spécifique
- pour chaque nœud.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>SLONYTESTER</envar></glossterm>
-
- <glossdef>
- <para>
- Adresse e-mail de la personne qui reçoit les résultats des tests.
- Ceci est stocké dans <envar>SLONYTESTFILE</envar> et peut être agrégé
- dans un registre comparable à une ferme de compilation.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm><envar>SLONYTESTFILE</envar></glossterm>
-
- <glossdef>
- <para>
- Fichier dans lequel sont stockés les résultats des tests. Ces résultats
- peuvent être utilisés pour construire un dépôt contenant l'agrégation
- des résultats de test.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry>
- <glossterm>
- <filename>random_number</filename> et <filename>random_string</filename>
- </glossterm>
-
- <glossdef>
- <para>
- Si vous exécutez <command>make</command> dans le répertoire de
- <filename>test</filename>, les programmes C
- <application>random_number</application> et
- <application>random_string</application> seront compilés et seront
- ensuite utilisés lors de la génération de données aléatoires au lieu
- d'utiliser les fonctions shell/SQL qui sont beaucoup plus lentes que
- les programmes C.
- </para>
- </glossdef>
- </glossentry>
</glosslist>
<para>
Modified: traduc/trunk/slony/usingslonik.xml
===================================================================
--- traduc/trunk/slony/usingslonik.xml 2009-02-20 23:00:00 UTC (rev 1243)
+++ traduc/trunk/slony/usingslonik.xml 2009-02-23 15:43:58 UTC (rev 1244)
@@ -149,6 +149,14 @@
node 2 admin conninfo = 'dbname=$DB2';
try {
+ table add key (node id = 1, fully qualified name =
+ 'public.history');
+ }
+ on error {
+ exit 1;
+ }
+
+ try {
create set (id = 1, origin = 1, comment =
'Set 1 - pgbench tables');
set add table (set id = 1, origin = 1,
@@ -162,7 +170,7 @@
comment = 'Table tellers');
set add table (set id = 1, origin = 1,
id = 4, fully qualified name = 'public.history',
- comment = 'Table accounts');
+ key = serial, comment = 'Table accounts');
}
on error {
exit 1;
@@ -205,6 +213,12 @@
slonik <<_EOF_
$PREAMBULE
try {
+ table add key (node id = $origin, fully qualified name =
+ 'public.history');
+} on error {
+ exit 1;
+}
+try {
create set (id = $mainset, origin = $origin,
comment = 'Set $mainset - pgbench tables');
set add table (set id = $mainset, origin = $origin,
@@ -218,7 +232,7 @@
comment = 'Table tellers');
set add table (set id = $mainset, origin = $origin,
id = 4, fully qualified name = 'public.history',
- comment = 'Table accounts');
+ key = serial, comment = 'Table accounts');
} on error {
exit 1;
}
@@ -250,6 +264,12 @@
slonik <<_EOF_
$PREAMBULE
try {
+ table add key (node id = $origin, fully qualified name =
+ 'public.history');
+} on error {
+ exit 1;
+}
+try {
create set (id = $mainset, origin = $origin,
comment = 'Set $mainset - pgbench tables');
$ADDTABLES
More information about the Trad
mailing list