[Trad] [svn:pgfr] r1248 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Lun 23 Fév 16:50:16 CET 2009
Author: gleu
Date: 2009-02-23 16:50:16 +0100 (Mon, 23 Feb 2009)
New Revision: 1248
Modified:
traduc/trunk/slony/addthings.xml
traduc/trunk/slony/adminscripts.xml
traduc/trunk/slony/bestpractices.xml
traduc/trunk/slony/cluster.xml
traduc/trunk/slony/concepts.xml
traduc/trunk/slony/defineset.xml
traduc/trunk/slony/dropthings.xml
traduc/trunk/slony/failover.xml
traduc/trunk/slony/filelist.xml
traduc/trunk/slony/firstdb.xml
traduc/trunk/slony/help.xml
traduc/trunk/slony/installation.xml
traduc/trunk/slony/intro.xml
traduc/trunk/slony/legal.xml
traduc/trunk/slony/listenpaths.xml
traduc/trunk/slony/locking.xml
traduc/trunk/slony/loganalysis.xml
traduc/trunk/slony/logshipping.xml
traduc/trunk/slony/maintenance.xml
traduc/trunk/slony/monitoring.xml
traduc/trunk/slony/partitioning.xml
traduc/trunk/slony/releasechecklist.xml
traduc/trunk/slony/reshape.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
traduc/trunk/slony/version.xml
traduc/trunk/slony/versionupgrade.xml
Log:
Mise ?\195?\160 jour vers la version 2.0.
N'est pas encore merg?\195?\169 : faq.xml et schemadoc.xml.
Modified: traduc/trunk/slony/addthings.xml
===================================================================
--- traduc/trunk/slony/addthings.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/addthings.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -336,6 +336,15 @@
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>
@@ -411,10 +420,10 @@
<listitem>
<para>
- À cet instant, lancer le script <command>test_slony_state-dbi.pl</command>
- est une excellente idée. Ce script parcourt le cluster tout entier et
- pointe les anomalies qu'il trouve. Il peut notamment identifier une grande
- variété de problèmes de communication.
+ À cet instant, lancer le script <eststate; est une excellente idée. Ce
+ script parcourt le cluster tout entier et pointe les anomalies qu'il
+ trouve. Il peut notamment identifier une grande variété de problèmes
+ de communication.
</para>
</listitem>
@@ -504,10 +513,10 @@
<listitem>
<para>
- Lancer le script <command>test_slony_state-dbi.pl</command> qui se trouve
- dans le répertoire <filename>tools</filename>. Ce script parcourt le cluster
- tout entier et pointe les anomalies qu'il détecte, ainsi que des
- informations sur le statut de chaque nœud.
+ Lancer le script <eststate; qui se trouve dans le répertoire
+ <filename>tools</filename>. Ce script parcourt le cluster tout entier et
+ pointe les anomalies qu'il détecte, ainsi que des informations sur le
+ statut de chaque nœud.
</para>
</listitem>
</itemizedlist>
Modified: traduc/trunk/slony/adminscripts.xml
===================================================================
--- traduc/trunk/slony/adminscripts.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/adminscripts.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -206,7 +206,7 @@
</sect3>
-<sect3>
+<sect3 id="slonik-drop-node">
<title>slonik_drop_node</title>
<para>
@@ -216,7 +216,7 @@
</sect3>
-<sect3>
+<sect3 id="slonik-drop-set">
<title>slonik_drop_set</title>
<para>
@@ -225,6 +225,19 @@
séquences).
</para>
+<para>
+ This represents a pretty big potential <quote>foot gun</quote>
+ as this eliminates a replication set all at once. A typo that points
+ it to the wrong set could be rather damaging. Compare to <xref
+ linkend="slonik-unsubscribe-set"/> and <xref
+ linkend="slonik-drop-node"/>; with both of those, attempting to drop a
+ subscription or a node that is vital to your operations will be
+ blocked (via a foreign key constraint violation) if there exists a
+ downstream subscriber that would be adversely affected. In contrast,
+ there will be no warnings or errors if you drop a set; the set will
+ simply disappear from replication.
+</para>
+
</sect3>
<sect3 id="slonik-drop-table">
@@ -400,13 +413,13 @@
<para>
Cette commande parcourt le cluster et supprime le schéma &slony1; sur tous
les nœuds. Vous pouvez utiliser cet outil si vous souhaitez détruire
- la réplication sur l'ensemble du cluster. Il s'agit d'un script
- <emphasis>TRÈS</emphasis> dangereux !
+ la réplication sur l'ensemble du cluster. Comme ses effets sont
+ nécessairement destructeurs, ce script peut devenir très dangereux.
</para>
</sect3>
-<sect3>
+<sect3 id="slonik-unsubscribe-set">
<title>slonik_unsubscribe_set</title>
<para>
@@ -562,15 +575,142 @@
</sect2>
+<sect2 id="startslon">
+<title>start_slon.sh</title>
+
+<para>
+ This <filename>rc.d</filename>-style script was introduced in
+ &slony1; version 2.0; it provides automatable ways of:
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Starting the &lslon;, via <command> start_slon.sh start </command>
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Attempts to start the &lslon;, checking first to verify that it
+ is not already running, that configuration exists, and that the log
+ file location is writable. Failure cases include:
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ No <link linkend="runtime-config"> slon runtime configuration file </link> exists,
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A &lslon; is found with the PID indicated via the runtime configuration,
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The specified <envar>SLON_LOG</envar> location is not writable.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Stopping the &lslon;, via <command> start_slon.sh stop </command>
+ </para>
+
+ <para>
+ This fails (doing nothing) if the PID (indicated via the runtime configuration file) does not exist;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Monitoring the status of the &lslon;, via <command> start_slon.sh status </command>
+ </para>
+
+ <para>
+ This indicates whether or not the &lslon; is running, and, if so, prints out the process ID.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ The following environment variables are used to control &lslon; configuration:
+</para>
+
+<glosslist>
+ <glossentry>
+ <glossterm>
+ <envar> SLON_BIN_PATH </envar>
+ </glossterm>
+
+ <glossdef>
+ <para>
+ This indicates where the &lslon; binary program is found.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>
+ <envar> SLON_CONF </envar>
+ </glossterm>
+
+ <glossdef>
+ <para>
+ This indicates the location of the <link linkend="runtime-config"> slon
+ runtime configuration file </link> that controls how the &lslon; behaves.
+ </para>
+
+ <para>
+ Note that this file is <emphasis>required</emphasis> to contain a value
+ for <link linkend="slon-config-logging-pid-file">log_pid_file</link>;
+ that is necessary to allow this script to detect whether the &lslon; is
+ running or not.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>
+ <envar> SLON_LOG </envar>
+ </glossterm>
+
+ <glossdef>
+ <para>
+ This file is the location where &lslon; log files are to be stored,
+ if need be. There is an option <xref
+ linkend ="slon-config-logging-syslog"/> for &lslon; to use
+ <application>syslog</application> to manage logging; in that case,
+ you may prefer to set <envar>SLON_LOG</envar> to
+ <filename>/dev/null</filename>.
+ </para>
+ </glossdef>
+ </glossentry>
+</glosslist>
+
+<para>
+ Note that these environment variables may either be set, in the
+ script, or overridden by values passed in from the environment. The
+ latter usage makes it easy to use this script in conjunction with the
+ <xref linkend="testbed"/> so that it is regularly tested.
+</para>
+
+</sect2>
+
<sect2 id="launchclusters">
<title>launch_clusters.sh</title>
<indexterm><primary>lancer un cluster &slony1; cluster en utilisant les fichiers slon.conf</primary></indexterm>
<para>
Voici un autre script shell qui utilise la configuration produite par
- <filename>mkslonconf.sh</filename> et qui peut être utilisé lors du démarrage
- du système, à la suite des processus <filename>rc.d</filename> ou dans un
- processus cron, pour s'assurer que les processus &lslon; fonctionnent.
+ <filename>mkslonconf.sh</filename> and is intended to support an approach
+ to running &slony1; involving regularly
+ (<emphasis>e.g.</emphasis> via a cron process) checking to ensure that
+ &lslon; processes are running
</para>
<para>
@@ -703,23 +843,6 @@
</listitem>
</itemizedlist>
-<note>
- <para>
- Ce script fonctionne correctement uniquement lorsqu'il est exécuté sur un
- nœud <emphasis>origine</emphasis>.
- </para>
-</note>
-
-<warning>
- <para>
- Si ce script est exécuté sur un nœud <emphasis>abonné</emphasis>,
- le <command>pg_dump</command> utilisé pour dessiner le schéma à partir du
- nœud source tentera de récupérer le schéma <emphasis>cassé</emphasis>
- trouvé sur l'abonne et, du coup, le résultat ne sera <emphasis>pas</emphasis>
- une représentation fidèle du schéma disponible sur le nœud origine.
- </para>
-</warning>
-
</sect2>
<sect2>
@@ -1080,9 +1203,13 @@
<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
+ Dans le répertoire <filename>tools</filename>, le script
<filename>slon.in-profiles</filename> permet de lancer des instances &lslon;
lors du démarrage du système. Il est conçu pour interagir avec le système des
ports de FreeBSD.
@@ -1090,4 +1217,118 @@
</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-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/bestpractices.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -149,9 +149,8 @@
<para>
Le système va périodiquement faire un troncage (en utilisant
<command>TRUNCATE</command> pour nettoyer l'ancienne table) entre les
- deux tables de logs, <xref linkend="table.sl-log-1"/> et <xref
- linkend="table.sl-log-2"/>, évitant une croissance illimitée de
- l'espace <quote>mort</quote> à cet endroit.
+ deux tables de logs, &sllog1; et &sllog2;, évitant une croissance
+ illimitée de l'espace <quote>mort</quote> à cet endroit.
</para>
</listitem>
</itemizedlist>
@@ -164,6 +163,13 @@
</para>
<para>
+ Most pointedly, any node that is expected to be a failover
+ target must have its subscription(s) set up with the option
+ <command>FORWARD = YES</command>. Otherwise, that node is not a
+ candidate for being promoted to origin node.
+ </para>
+
+ <para>
Cela peut simplement se résumer à réfléchir à une liste de priorités
indiquant qui devrait basculer vers quoi, plutôt que d'essayer
d'automatiser la bascule. Quoiqu'il en soit, savoir au préalable ce
@@ -205,6 +211,21 @@
<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>
@@ -234,10 +255,13 @@
réseau</quote> que le nœud d'origine, afin que la liaison entre
eux soit une connexion <quote>locale</quote>. N'établissez
<emphasis>pas</emphasis> ce genre de liaison à travers un réseau WAN.
+ Thus, if you have nodes in London and nodes in New
+ York, the &lslon;s managing London nodes should run in London, and the
+ &lslon;s managing New York nodes should run in New York.
</para>
<para>
- Une coupure de lien WAN peut provoquer des connexions
+ Une coupure de lien WAN (or flakiness of the WAN in general) peut provoquer des connexions
<quote>zombies</quote>, et le comportement typique du TCP/IP consiste à
<link linkend="multipleslonconnections">laisser ces connexions persister,
empêchant le démon slon de redémarrer pendant environ deux heures</link>.
@@ -270,7 +294,7 @@
</para>
<para>
- L'exception qui rend un redémarrage de &lslon; indésirable est le cas où
+ Le scénario d'exception qui rend un redémarrage de &lslon; indésirable est le cas où
une commande <command>COPY_SET</command> est en cours d'exécution sur un
grand ensemble de réplication. Dans ce genre de cas, arrêter un &lslon;
peut annuler plusieurs heures de travail.
@@ -314,6 +338,14 @@
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>
@@ -387,8 +419,10 @@
verrou exclusif sur ces objets ; ainsi le <command>script
d'exécution des modifications</command> entraîne un verrou exclusif sur
<emphasis>toutes</emphasis> les tables répliquées. Cela peut s'avérer
- très problématique lorsque les applications fonctionnent ; des
- inter-blocages (« deadlocks ») peuvent alors se produire.
+ très problématique si les applications fonctionnent when running DDL;
+ &slony1; is asking for those exclusive table locks, whilst,
+ simultaneously, some application connections are gradually relinquishing
+ locks, whilst others are backing up behind the &slony1; locks.
</para>
<para>
@@ -636,8 +670,8 @@
<listitem>
<para>
- Utilisez <filename>test_slony_state.pl</filename> pour rechercher les
- problèmes de configuration.
+ Run <eststate; frequently to discover configuration
+ problems as early as possible.
</para>
<para>
@@ -656,6 +690,14 @@
Si, de manière mystérieuse, la réplication <quote>ne marche pas</quote>,
cet outil peut vérifier beaucoup de problèmes potentiels pour vous.
</para>
+
+ <para>
+ It will also notice a number of sorts of situations where something
+ has broken. Not only should it be run when problems have been noticed
+ - it should be run frequently (<emphasis>e.g.</emphasis> - hourly, or
+ thereabouts) as a general purpose <quote>health check</quote> for each
+ &slony1; cluster.
+ </para>
</listitem>
<listitem>
@@ -714,6 +756,16 @@
verrouiller l'accès au nœud pour tous les utilisateurs autres que
<command>slony</command> car :
</para>
+
+ <para>
+ It is also a very good idea to change &lslon; configuration for
+ <xref linkend="slon-config-sync-interval"/> on the origin node to
+ reduce how many <command>SYNC</command> events are generated. If the
+ subscription takes 8 hours, there is little sense in there being 28800
+ <command>SYNC</command>s waiting to be applied. Running a
+ <command>SYNC</command> every minute or so is likely to make catching
+ up easier.
+ </para>
</listitem>
</itemizedlist>
@@ -829,9 +881,8 @@
<para>
Parallèlement, on constate une croissance <emphasis>énorme</emphasis>
- des tables <xref linkend="table.sl-log-1"/> et <xref
- linkend="table.sl-seqlog"/>. Malheureusement, une fois que
- <command>COPY_SET</command> est terminé, on constate que les requêtes
+ des tables &sllog1;, &sllog2; et &slseqlog;. Malheureusement, une fois
+ que <command>COPY_SET</command> est terminé, on constate que les requêtes
sur ces tables se font via des <command>parcours séquentiels</command>.
Même si le <command>SYNC</command> ne traite qu'une petite partie de
ces 90 000 événements <command>SYNC</command>, la table sera lue
@@ -855,7 +906,7 @@
</para>
<para>
- Dans les versions 1.2 et suivantes, il y a un processus qui ajoute
+ En 1.2, il y a un processus qui ajoute
automatiquement les index partiels par numéro de nœud d'origine,
ce qui est la forme optimale pour ces index.
</para>
Modified: traduc/trunk/slony/cluster.xml
===================================================================
--- traduc/trunk/slony/cluster.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/cluster.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -19,10 +19,9 @@
qui stockent la configuration de &slony1; et les informations sur l'état
de la réplication.
Consultez <xref linkend="schema"/> pour plus d'informations sur
- ce qui est stocké dans ce schéma. Plus précisément, les tables
- <xref linkend="table.sl-log-1"/> et <xref linkend="table.sl-log-2"/>
- tracent les modifications collectées sur le nœud d'origine afin
- qu'elles soient répliquées sur les nœuds abonnés.
+ ce qui est stocké dans ce schéma. Plus précisément, les tables &sllog1; et
+ &sllog2; tracent les modifications collectées sur le nœud d'origine
+ afin qu'elles soient répliquées sur les nœuds abonnés.
</para>
<para>
@@ -36,6 +35,13 @@
</para>
<para>
+ Note that, as recorded in the <xref linkend="faq"/> under <link
+ linkend="cannotrenumbernodes"> How can I renumber nodes?</link>, the
+ node number is immutable, so it is not possible to change a node's
+ node number after it has been set up.
+</para>
+
+<para>
Une réflexion doit être menée, dans des cas plus complexes,
afin de s'assurer que le système de numérotation reste cohérent,
sans quoi les administrateurs deviendront fous. Les numéros de nœud
Modified: traduc/trunk/slony/concepts.xml
===================================================================
--- traduc/trunk/slony/concepts.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/concepts.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -56,7 +56,7 @@
</para>
<programlisting>
-cluster name = 'quelque_chose';
+cluster name = quelque_chose;
</programlisting>
<para>
Modified: traduc/trunk/slony/defineset.xml
===================================================================
--- traduc/trunk/slony/defineset.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/defineset.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -108,12 +108,18 @@
<listitem>
<para>
Si la table n'a pas de clef primaire candidate, vous devez demander à
- &slony1; d'en fournir une. Tout d'abord, vous devez utiliser <xref
- linkend="stmttableaddkey"/> pour ajouter une colonne peuplée en utilisant
- une séquence &slony1;. Ensuite, <xref linkend="stmtsetaddtable"/> inclut
- la directive <option>key=serial</option> pour indiquer que la propre
- colonne de &slony1; doit être utilisé.
+ &slony1; d'en produire une en utilisant la commande <xref
+ linkend="stmttableaddkey"/>.
</para>
+
+ <warning>
+ <para>
+ La commande <xref linkend="stmttableaddkey"/> a toujours été considérée
+ au mieux comme un <quote>bricolage</quote>, et à partir de la version
+ 2.0, elle est considérée comme une mauvaise fonctionnalité qu'il faut
+ supprimer.
+ </para>
+ </warning>
</listitem>
</itemizedlist>
@@ -168,6 +174,18 @@
</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
@@ -223,7 +241,7 @@
Chaque fois qu'un évènement SYNC est traité, les valeurs sont enregistrées
pour <emphasis>toutes</emphasis> les séquences de l'ensemble de réplication.
Si vous avez beaucoup de séquences, cela peut augmenter fortement la
- volumétrie de la table <xref linkend="table.sl-seqlog"/> .
+ volumétrie de la table &slseqlog;.
</para>
<para>
@@ -244,12 +262,12 @@
<para>
Si elle n'est jamais mise à jour, le trigger de la table sur le
nœud origine n'est jamais déclenché, et aucune entrée n'est
- ajoutée dans <xref linkend="table.sl-log-1"/>. La table n'apparaît
+ ajoutée dans &sllog1;/&sllog2;. La table n'apparaît
jamais dans aucune des requêtes de réplication (<emphasis>par
exemple :</emphasis> dans les requêtes <command>FETCH 100 FROM
LOG</command> utilisées pour trouver les données à répliquer) car elles
ne recherchent que les tables qui ont des entrées dans
- <xref linkend="table.sl-log-1"/>.
+ &sllog1;/&sllog2;.
</para>
</listitem>
@@ -261,7 +279,9 @@
<para>
Pour répliquer 300 séquences, 300 lignes doivent être ajoutées dans la
- <xref linkend="table.sl-seqlog"/> de manière régulière.
+ &slseqlog; de manière régulière, at least, thru until the 2.0 branch,
+ where updates are only applied when the value of a given sequence is
+ seen to change.
</para>
<para>
Modified: traduc/trunk/slony/dropthings.xml
===================================================================
--- traduc/trunk/slony/dropthings.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/dropthings.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -214,4 +214,16 @@
</sect2>
+<sect2>
+<title>Vérifier la santé du cluster</title>
+
+<para>
+ Après avoir exécuté ces procédures, exécuter le script <eststate; du
+ répertoire <filename>tools</filename> est une excellente idée. Il parcourt
+ tout le cluster, pointant toutes les anomalies qu'il trouve. Parmi
+ celles-ci se trouvent aussi des tests sur les problèmes de communication.
+</para>
+
+</sect2>
+
</sect1>
Modified: traduc/trunk/slony/failover.xml
===================================================================
--- traduc/trunk/slony/failover.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/failover.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -59,12 +59,69 @@
<itemizedlist>
<listitem>
<para>
- Au moment ou nous écrivons ces lignes, basculer vers un autre serveur
- nécessite que l'application se reconnecte à la base de donnée.
+ Au moment où nous écrivons ces lignes, basculer vers un autre serveur
+ nécessite que l'application se reconnecte à la nouvelle base de donnée.
Donc, pour éviter toute complication, nous éteignons le serveur web. Les
utilisateurs qui ont installé <application>pgpool</application> pour
gérer les connexions peuvent simplement éteindre le pool.
</para>
+
+ <para>
+ Les actions à mener dépendent beaucoup de la configuration des
+ applications qui utilisent la base de données. En général, les
+ applications qui étaient connectées à l'ancienne base doivent détruire
+ leurs connexions et en établir de nouvelles vers la base qui vient d'être
+ promue dans le rôle du <quote>/maître/</quote>. Il y a différentes façons
+ de configurer cela, et donc différentes façon d'effectuer la bascule :
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ L'application stocke le nom de la base de donnée dans un fichier.
+ </para>
+
+ <para>
+ Dans ce cas, la reconfiguration nécessite de changer la valeur dans
+ ce fichier, d'arrêter puis de relancer l'application pour qu'elle
+ pointe vers le nouvel emplacement des données.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Une utilisation pertinente de DNS consiste à créer des <ulink
+ url="http://www.iana.org/assignments/dns-parameters">champs DNS</ulink>
+ CNAME qui permettent à l'application d'utiliser un nom pour
+ référencer le nœud qui joue le rôle du nœud
+ <quote>maître</quote>.
+ </para>
+
+ <para>
+ Dans ce cas, la reconfiguration nécessite de changer le CNAME pour
+ pointer vers le nouveau serveur. De plus, il faut probablement
+ relancer l'application pour rafraîchir les connexions à la base.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si vous utilisez <application>pgpool</application> ou un
+ <quote>gestionnaire de connexions</quote> similaire, alors la
+ reconfiguration implique de modifier le paramètrage de cet outil,
+ à part cela la procédure est similaire à l'exemple DNS/CNAME
+ ci-dessus.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ La nécessité de redémarrer l'application qui se connecte à la base dépend
+ de la manière dont elle a été conçue et des mécanismes de gestion d'erreurs
+ de connexion qui ont été implémentés ; si à la suite d'une erreur
+ elle tente d'ouvrir à nouveau une connexion, alors il n'est pas nécessaire
+ de la relancer.
+ </para>
</listitem>
<listitem>
@@ -118,6 +175,13 @@
n'implique aucune perte de données.
</para>
+<para>
+ After performing the configuration change, you should, as <xref
+ linkend="bestpractices"/>, run the <eststate; scripts in order to
+ validate that the cluster state remains in good order after this
+ change.
+</para>
+
</sect2>
<sect2>
@@ -173,6 +237,18 @@
de bascule d'urgence est complétée, plus aucun nœud du cluster ne
reçoit d'information de la part du nœud 1.
</para>
+
+ <note>
+ <para>
+ Note that in order for node 2 to be considered as a
+ candidate for failover, it must have been set up with the <xref
+ linkend="stmtsubscribeset"/> option <command>forwarding =
+ yes</command>, which has the effect that replication log data is
+ collected in &sllog1;/&sllog2; on node 2. If replication log data is
+ <emphasis>not</emphasis> being collected, then failover to that node
+ is not possible.
+ </para>
+ </note>
</listitem>
<listitem>
@@ -192,7 +268,7 @@
références au nœud 1 dans la table <xref linkend="table.sl-node"/>,
ainsi que ses tables associées telle que <xref
linkend="table.sl-confirm"/> ; puisque des données sont toujours
- présentes dans <xref linkend="table.sl-log-1"/>, &slony1; ne peut pas
+ présentes dans &sllog1;/&sllog2;, &slony1; ne peut pas
purger immédiatement le nœud.
</para>
@@ -215,6 +291,15 @@
linkend="rebuildnode1"/> pour plus de détails sur ce que cela implique.
</para>
</listitem>
+
+ <listitem>
+ <para>
+ After performing the configuration change, you should, as <xref
+ linkend="bestpractices"/>, run the <eststate; scripts in order
+ to validate that the cluster state remains in good order after
+ this change.
+ </para>
+ </listitem>
</itemizedlist>
</sect2>
Modified: traduc/trunk/slony/filelist.xml
===================================================================
--- traduc/trunk/slony/filelist.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/filelist.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -48,7 +48,9 @@
<!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-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/firstdb.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -41,8 +41,15 @@
<listitem>
<para>
Vous avez la ligne <option>tcpip_socket=true</option> dans votre
- <filename>postgresql.conf</filename> et
+ <filename>postgresql.conf</filename>.
</para>
+
+ <note>
+ <para>
+ Ce n'est plus nécessaire pour les versions &postgres; 8.0 et
+ ultérieures.
+ </para>
+ </note>
</listitem>
<listitem>
@@ -127,6 +134,27 @@
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
@@ -179,41 +207,33 @@
principalement des procédures stockées sur les nœuds maître et esclaves.
</para>
-<sect3><title>Utiliser les scripts altperl</title>
-<indexterm><primary>Utilisation des scripts altperl</primary></indexterm>
-
<para>
- L'utilisation des scripts <xref linkend="altperl"/> est une façon simple de
- faire ses premiers pas. Le script <command>slonik_build_env</command> génère
- une sortie fournissant les détails nécessaires à la construction complète
- d'un fichier <filename>rslon_tools.conf</filename>. Un exemple de fichier
- <filename>slon_tools.conf</filename> est fournit dans la distribution afin
- d'aider à la prise en main. Les script altperl font tous référence à ce
- fichier central de configuration afin de simplifier l'administration. Une
- fois le fichier slon_tools.conf créé, vous pouvez poursuivre comme ceci :
+ The example that follows uses <xref linkend="slonik"/> directly
+ (or embedded directly into scripts). This is not necessarily the most
+ pleasant way to get started; there exist tools for building <xref
+ linkend="slonik"/> scripts under the <filename>tools</filename>
+ directory, including:
</para>
-<programlisting># Initialisation du cluster:
-$ slonik_init_cluster | slonik
+<itemizedlist>
+ <listitem>
+ <para>
+ <xref linkend="altperl"/> - a set of Perl scripts that build <xref
+ linkend="slonik"/> scripts based on a single
+ <filename>slon_tools.conf</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <xref linkend="mkslonconf"/> - a shell script (<emphasis>e.g.</emphasis>
+ - works with Bash) which, based either on self-contained configuration
+ or on shell environment variables, generates a set of <xref
+ linkend="slonik"/> scripts to configure a whole cluster.
+ </para>
+ </listitem>
+</itemizedlist>
-# Démarrage de slon (ici 1 et 2 sont les numéros de nœuds)
-$ slon_start 1
-$ slon_start 2
-
-# Création des ensemble (ici 1 est le numéro de l'ensemble)
-$ slonik_create_set 1
-
-# Abonner l'ensemble dans le second nœud (1= n° d'ensemble, 2= n° de nœud)
-$ slonik_subscribe_set 1 2 | slonik</programlisting>
-
-<para>
- Vous avez répliqué votre première base de données. Vous pouvez sauter la
- section suivante de la documentation si vous le souhaitez car il s'agit
- d'une approche plus <quote>rustre</quote>.
-</para>
-
-</sect3>
-
<sect3>
<title>Utiliser directement les commandes slonik</title>
@@ -275,7 +295,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', key = serial);
+ set add table (set id=1, origin=1, id=4, fully qualified name = 'public.history', comment='history table');
#--
# Création du second noeud (l'esclave)
@@ -359,7 +379,8 @@
Lorsque le processus de copie est terminé, le démon de réplication sur le
nœud <envar>$SLAVEHOST</envar> commencera à se synchroniser en
appliquant les journaux de réplication qui auront été accumulés. Cela se
- fera par petit à petit, par tranches de 10 secondes de travail applicatifs.
+ fera par petit à petit, en commençant par tranches de 10 secondes de travail
+ applicatifs.
Selon les performances des deux systèmes impliqués, la taille des deux bases
de données, la charge de transaction et la qualité de l'optimisation et de la
maintenance effectuées sur les deux bases de données, ce processus de
@@ -368,6 +389,14 @@
</para>
<para>
+ If you encounter problems getting this working, check over the
+ logs for the &lslon; processes, as error messages are likely to be
+ suggestive of the nature of the problem. The tool <eststate; is
+ also useful for diagnosing problems with nearly-functioning
+ replication clusters.
+</para>
+
+<para>
Vous avez maintenant configuré avec succès votre premier système de
réplication maître-esclave basique, et les deux bases de données devraient,
une fois que l'esclave sera synchronisé, contenir des données identiques. Ça,
@@ -426,10 +455,53 @@
<para>
Si ce script renvoie <command>FAILED</command>, merci de contacter les
développeurs sur <ulink url="http://slony.info/">http://slony.info/</ulink>.
+ Be sure to be prepared with useful diagnostic information including the
+ logs generated by &lslon; processes and the output of <eststate;.
</para>
</sect3>
+<sect3>
+<title>Using the altperl scripts</title>
+<indexterm><primary> altperl script example </primary></indexterm>
+
+<para>
+ Using the <xref linkend="altperl"/> scripts is an alternative way to
+ get started; it allows you to avoid writing slonik scripts, at least
+ for some of the simple ways of configuring &slony1;. The
+ <command>slonik_build_env</command> script will generate output
+ providing details you need to build a
+ <filename>slon_tools.conf</filename>, which is required by these
+ scripts. An example <filename>slon_tools.conf</filename> is provided
+ in the distribution to get you started. The altperl scripts all
+ reference this central configuration file centralize cluster
+ configuration information. Once slon_tools.conf has been created, you
+ can proceed as follows:
+</para>
+
+<programlisting>
+# Initialize cluster:
+$ slonik_init_cluster | slonik
+
+# Start slon (here 1 and 2 are node numbers)
+$ slon_start 1
+$ slon_start 2
+
+# Create Sets (here 1 is a set number)
+$ slonik_create_set 1 | slonik
+
+# subscribe set to second node (1= set ID, 2= node ID)
+$ slonik_subscribe_set 1 2 | slonik
+</programlisting>
+
+<para>
+ You have now replicated your first database. You can skip the
+ following section of documentation if you'd like, which documents more
+ of a <quote>bare-metal</quote> approach.
+</para>
+
+</sect3>
+
</sect2>
</sect1>
Modified: traduc/trunk/slony/help.xml
===================================================================
--- traduc/trunk/slony/help.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/help.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -24,7 +24,7 @@
Avant de soumettre des questions sur un forum public en demandant
pourquoi <quote>quelque chose d'étrange</quote> s'est produit dans
votre cluster de réplication, veuillez lancer la commande
- <xref linkend="testslonystate"/>.
+ <eststate; et préparez-vous à fournir le résultat de cette commande.
Cela peut vous donner plus d'idées sur ce qui ne va pas, et les
résultats seront sûrement d'une grande aide dans l'analyse du
problème.
Modified: traduc/trunk/slony/installation.xml
===================================================================
--- traduc/trunk/slony/installation.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/installation.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -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 2005. Les distribution Fedora actuelles ont déjà corrigé ce
+ pas le cas en 2008. Les distribution Fedora actuelles ont déj) corrigé ce
problème.
</para>
Modified: traduc/trunk/slony/intro.xml
===================================================================
--- traduc/trunk/slony/intro.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/intro.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -424,7 +424,7 @@
Chaque événement SYNC appliqué doit être annoncé à tous les nœuds
participants à la réplication de l'ensemble de données, afin que chaque
nœud sache qu'il est possible de purger les données des tables
- <xref linkend="table.sl-log-1"/> et <xref linkend="table.sl-log-2"/>,
+ &sllog1; et &sllog2;,
car n'importe quel nœud <quote>fournisseur</quote> peut
potentiellement devenir un <quote>maître</quote> à tout moment. On peut
s'attendre à que les messages SYNC ne soient propagés que sur n/2
Modified: traduc/trunk/slony/legal.xml
===================================================================
--- traduc/trunk/slony/legal.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/legal.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -5,7 +5,7 @@
révision $Revision$ -->
<copyright>
- <year>2004-2006</year>
+ <year>2004-2007</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-2006
+ <productname>PostgreSQL</productname> est sous le Copyright &copy; 2004-2007
du PostgreSQL Global Development Group et est distribué sous les termes
de la licence de l'Université de Californie ci-dessous.
</para>
Modified: traduc/trunk/slony/listenpaths.xml
===================================================================
--- traduc/trunk/slony/listenpaths.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/listenpaths.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -34,11 +34,11 @@
<quote>parent</quote> qui leur transmet les mise à jours mais, en réalité,
ils doivent pouvoir recevoir des messages de la part de
<emphasis>tous</emphasis> les nœuds afin de pouvoir déterminer si les
- <command>SYNC</command>s ont été reçues partout et que les entrées de <xref
- linkend="table.sl-log-1"/> et <xref linkend="table.sl-log-2"/> ont été
- appliquées partout et qu'elles peuvent être purgées. Ces communications
- supplémentaires permettent à <productname>Slony-I</productname> de déplacer
- les origines vers d'autres nœuds.
+ <command>SYNC</command>s ont été reçues partout et que les entrées de
+ &sllog1; et &sllog2; ont été appliquées partout et qu'elles peuvent être
+ purgées. Ces communications supplémentaires permettent à
+ <productname>Slony-I</productname> de déplacer les origines vers d'autres
+ nœuds.
</para>
<sect2>
Modified: traduc/trunk/slony/locking.xml
===================================================================
--- traduc/trunk/slony/locking.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/locking.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -21,6 +21,10 @@
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.
+ &slony1; configuration events normally grab locks on an
+ internal table, <envar>sl_config_lock</envar>, which should not be
+ visible to applications unless they are performing actions on &slony1;
+ components.
</para>
<para>
Modified: traduc/trunk/slony/loganalysis.xml
===================================================================
--- traduc/trunk/slony/loganalysis.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/loganalysis.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -35,9 +35,29 @@
</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>
+ Debug notices are of less interest, and will quite likely only
+ need to be shown if you are running into some problem with &slony1;.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Thread name</title>
+
+<para>
Les notifications DEBUG sont moins intéressantes et ne vous seront utiles
que lorsque vous rencontrez une problème avec &slony1;.
</para>
Modified: traduc/trunk/slony/logshipping.xml
===================================================================
--- traduc/trunk/slony/logshipping.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/logshipping.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -432,7 +432,7 @@
-- Node 11, Event 656
start transaction;
-select "_T1".setsyncTracking_offline(1, '655', '656', '2005-09-23 18:37:40.206342');
+select "_T1".setsyncTracking_offline(1, '655', '656', '2007-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', '2005-09-23 19:01:31.267403');
+select "_T1".setsyncTracking_offline(1, '96', '109', '2007-09-23 19:01:31.267403');
-- end of log archiving header</programlisting>
</para>
@@ -525,6 +525,34 @@
</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-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/maintenance.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -16,9 +16,8 @@
<listitem>
<para>
supprime les anciennes données sur les différentes tables du schéma
- de <productname>Slony-I</productname>, notamment <xref
- linkend="table.sl-log-1"/>, <xref linkend="table.sl-log-2"/> et <xref
- linkend="table.sl-seqlog"/> ;
+ de <productname>Slony-I</productname>, notamment &sllog1;, &sllog2;
+ et &slseqlog; ;
</para>
</listitem>
@@ -54,22 +53,18 @@
<listitem>
<para>
Le bogue <link linkend="dupkey">violation par clef dupliquée</link> a
- permis d'isoler des situations de concurrence dans &postgres;. Des
- problèmes subsistent notamment lorsque <command>VACUUM</command> ne
- réclame pas correctement l'espace menant à une corruption des index de
- type B-tree.
+ permis d'isoler a number of rather obscure &postgres; race conditions,
+ so that in modern versions of &slony1; and &postgres;, there should be
+ little to worry about.
</para>
-
- <para>
- Il peut être utile de lancer la commande <command>REINDEX TABLE
- sl_log_1;</command> périodiquement pour éviter ce problème.
- </para>
</listitem>
<listitem>
<para>
À partir de la version 1.2, la fonctionnalité <quote>log
- switching</quote> est arrivée ;de temps en temps, elle tente
+ switching</quote> est arrivée ;de temps en temps (by default,
+ once per week, though you may induce it by calling the stored
+ function <function>logswitch_start()</function>), elle tente
d'interchanger les données entre &sllog1; et &sllog2; afin de réaliser
un <command>TRUNCATE</command> sur les <quote>plus vieilles</quote>
données.
@@ -80,10 +75,79 @@
nettoyées ce qui évite qu'elles ne grossissent trop lors d'une charge
importante et qu'elles deviennent impossibles à nettoyer.
</para>
+
+ <para>
+ In version 2.0, <command>DELETE</command> is no longer used to
+ clear out data in &sllog1; and &sllog2;; instead, the log switch logic
+ is induced frequently, every time the cleanup loop does not find a
+ switch in progress, and these tables are purely cleared out
+ via <command>TRUNCATE</command>. This eliminates the need to vacuum
+ these tables.
+ </para>
</listitem>
</itemizedlist>
</para>
+<sect2 id="maintenance-autovac">
+<title>Interaction avec l'autovacuum de &postgres;</title>
+<indexterm><primary>interaction avec autovacuum</primary></indexterm>
+
+<para>
+ Les versions récentes de&postgres; proposent un processus
+ <quote>autovacuum</quote> qui détecte les modifications sur les tables et
+ la création de lignes mortes, puis nettoie ces tables, <quote>à la
+ demande</quote>. On a constaté que cela peut interagir de manière négative
+ avec la politique de VACUUM de &slony1; sur ces propres tables.
+</para>
+
+<para>
+ &slony1; demande des VACUUM sur ses tables immédiatement après avoir complété
+ les transactions qui sont sensées supprimer de vieilles données, ce qui est
+ considéré comme le meilleur moment pour le faire. Il semble que l'autovacuum
+ détecte les changements un peu trop tôt, et lance un VACUUM alors que les
+ transactions ne sont pas terminées, ce qui est relativement inutile. Il
+ apparaît préférable de configurer l'autovacuum pour éviter les tables de
+ configuration gérées par &slony1;.
+</para>
+
+<para>
+ La requête suivante identifie les tables que l'autovacuum ne doit pas traiter
+ (remplacez le nom du cluster par celui de votre configuration locale) :
+</para>
+
+<programlisting>
+moncluster=# select oid, relname from pg_class where relnamespace = (select oid from pg_namespace where nspname = '_' || 'monCluster') and relhasindex;
+ oid | relname
+-------+--------------
+ 17946 | sl_nodelock
+ 17963 | sl_setsync
+ 17994 | sl_trigger
+ 17980 | sl_table
+ 18003 | sl_sequence
+ 17937 | sl_node
+ 18034 | sl_listen
+ 18017 | sl_path
+ 18048 | sl_subscribe
+ 17951 | sl_set
+ 18062 | sl_event
+ 18069 | sl_confirm
+ 18074 | sl_seqlog
+ 18078 | sl_log_1
+ 18085 | sl_log_2
+(15 rows)
+</programlisting>
+
+<para>
+ La requête suivante remplira la table <envar>pg_catalog.pg_autovacuum</envar>
+ avec les informations de configuration adéquates :
+ <command>INSERT INTO pg_catalog.pg_autovacuum (vacrelid, enabled)
+ SELECT oid, 'f' FROM pg_catalog.pg_class
+ WHERE relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = '_' || 'monCluster')
+ AND relhasindex;</command>
+</para>
+
+</sect2>
+
<sect2><title>Chiens de garde : garder les Slons en vie</title>
<indexterm><primary>Chiens de garde pour garder en vie les démons slon</primary></indexterm>
@@ -120,6 +184,7 @@
<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
@@ -167,7 +232,7 @@
<para>
Dans le répertoire <filename>tools</filename>, vous trouverez des scripts
- nommés <filename>test_slony_state.pl</filename> et
+ <eststate; nommés <filename>test_slony_state.pl</filename> et
<filename>test_slony_state-dbi.pl</filename>. Le premier utilise l'interface
Perl/DBI, l'autre utilise l'interface PostgreSQL.
</para>
@@ -312,6 +377,7 @@
</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
@@ -411,4 +477,190 @@
</sect2>
+<sect2><title>mkservice</title>
+<indexterm><primary>mkservice 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-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/monitoring.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -8,6 +8,299 @@
<title>Surveillance</title>
<indexterm><primary>Surveiller &slony1;</primary></indexterm>
+<para>
+ As a prelude to the discussion, it is worth pointing out that
+ since the bulk of &slony1; functionality is implemented via running
+ database functions and SQL queries against tables within a &slony1;
+ schema, most of the things that one might want to monitor about
+ replication may be found by querying tables in the schema created for
+ the cluster in each database in the cluster.
+</para>
+
+<para>
+ Here are some of the tables that contain information likely to
+ be particularly interesting from a monitoring and diagnostic
+ perspective.
+</para>
+
+<glosslist>
+ <glossentry>
+ <glossterm><envar>sl_status</envar></glossterm>
+
+ <glossdef>
+ <para>
+ This view is the first, most obviously useful thing to
+ look at from a monitoring perspective. It looks at the local node's
+ events, and checks to see how quickly they are being confirmed on
+ other nodes.
+ </para>
+
+ <para>
+ The view is primarily useful to run against an origin
+ (<quote>master</quote>) node, as it is only there where the events
+ generated are generally expected to require interesting work to be
+ done. The events generated on non-origin nodes tend to
+ be <command>SYNC</command> events that require no replication work be
+ done, and that are nearly no-ops, as a
+ result.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>&slconfirm;</glossterm>
+
+ <glossdef>
+ <para>
+ Contains confirmations of replication events; this may be used to infer
+ which events have, and <emphasis>have not</emphasis> been processed.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>&slevent;</glossterm>
+
+ <glossdef>
+ <para>
+ Contains information about the replication events processed on the
+ local node.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>&sllog1; and &sllog2;</glossterm>
+
+ <glossdef>
+ <para>
+ These tables contain replicable data. On an origin node, this is the
+ <quote>queue</quote> of data that has not necessarily been replicated
+ everywhere. By examining the table, you may examine the details of
+ what data is replicable.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>&slnode;</glossterm>
+
+ <glossdef>
+ <para>
+ The list of nodes in the cluster.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>&slpath;</glossterm>
+
+ <glossdef>
+ <para>
+ This table holds connection information indicating how &lslon;
+ processes are to connect to remote nodes, whether to access events,
+ or to request replication data.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>&sllisten;</glossterm>
+
+ <glossdef>
+ <para>
+ This configuration table indicates how nodes listen
+ for events coming from other nodes. Usually this is automatically
+ populated; generally you can detect configuration problems by this
+ table being <quote>underpopulated.</quote>
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>&slregistry;</glossterm>
+
+ <glossdef>
+ <para>
+ A configuration table that may be used to store
+ miscellaneous runtime data. Presently used only to manage switching
+ between the two log tables.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>&slseqlog;</glossterm>
+
+ <glossdef>
+ <para>
+ Contains the <quote>last value</quote> of replicated
+ sequences.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>&slset;</glossterm>
+
+ <glossdef>
+ <para>
+ Contains definition information for replication sets,
+ which is the mechanism used to group together related replicable
+ tables and sequences.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>&slsetsync;</glossterm>
+
+ <glossdef>
+ <para>
+ Contains information about the state of synchronization of each
+ replication set, including transaction snapshot data.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>&slsubscribe;</glossterm>
+
+ <glossdef>
+ <para>
+ Indicates what subscriptions are in effect for each replication set.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>&sltable;</glossterm>
+
+ <glossdef>
+ <para>
+ Contains the list of tables being replicated.
+ </para>
+ </glossdef>
+ </glossentry>
+</glosslist>
+
+<sect2 id="testslonystate">
+<title>test_slony_state</title>
+<indexterm><primary>script test_slony_state to test replication state</primary></indexterm>
+
+<para>
+ This invaluable script does various sorts of analysis of the
+ state of a &slony1; cluster. &slony1; <xref linkend="bestpractices"/>
+ recommend running these scripts frequently (hourly seems suitable) to
+ find problems as early as possible.
+</para>
+
+<para>
+ You specify arguments including <option>database</option>,
+ <option>host</option>, <option>user</option>,
+ <option>cluster</option>, <option>password</option>, and
+ <option>port</option> to connect to any of the nodes on a cluster.
+ You also specify a <option>mailprog</option> command (which should be
+ a program equivalent to <productname>Unix</productname>
+ <application>mailx</application>) and a recipient of email.
+</para>
+
+<para>
+ You may alternatively specify database connection parameters
+ via the environment variables used by
+ <application>libpq</application>, <emphasis>e.g.</emphasis> - using
+ <envar>PGPORT</envar>, <envar>PGDATABASE</envar>,
+ <envar>PGUSER</envar>, <envar>PGSERVICE</envar>, and such.
+</para>
+
+<para>
+ The script then rummages through <xref linkend="table.sl-path"/>
+ to find all of the nodes in the cluster, and the DSNs to allow it to,
+ in turn, connect to each of them.
+</para>
+
+<para>
+ For each node, the script examines the state of things,
+ including such things as:
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Checking <xref linkend="table.sl-listen"/> for some
+ <quote>analytically determinable</quote> problems. It lists paths
+ that are not covered.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Providing a summary of events by origin node
+ </para>
+
+ <para>
+ If a node hasn't submitted any events in a while, that likely
+ suggests a problem.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Summarizes the <quote>aging</quote> of table <xref linkend="table.sl-confirm"/>
+ </para>
+
+ <para>
+ If one or another of the nodes in the cluster hasn't reported
+ back recently, that tends to lead to cleanups of tables like &sllog1;,
+ &sllog2; and &slseqlog; not taking place.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Summarizes what transactions have been running for a
+ long time
+ </para>
+
+ <para>
+ This only works properly if the statistics collector is
+ configured to collect command strings, as controlled by the option
+ <option> stats_command_string = true </option> in <filename>
+ postgresql.conf </filename>.
+ </para>
+
+ <para>
+ If you have broken applications that hold connections open,
+ this will find them.
+ </para>
+
+ <para>
+ If you have broken applications that hold connections open,
+ that has several unsalutory effects as <link
+ linkend="longtxnsareevil"> described in the
+ FAQ</link>.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ The script does some diagnosis work based on parameters in the
+ script; if you don't like the values, pick your favorites!
+</para>
+
+<note>
+ <para>
+ Note that there are two versions, one using the
+ <quote>classic</quote> <filename>Pg.pm</filename> Perl module for
+ accessing &postgres; databases, and one, with <filename>dbi</filename>
+ in its name, that uses the newer Perl <function> DBI</function>
+ interface. It is likely going to be easier to find packaging for
+ <function>DBI</function>.
+ </para>
+</note>
+
+</sect2>
+
<sect2>
<title>Tester la replication avec &nagios;</title>
<indexterm><primary>&nagios; pour surveiller la réplication</primary></indexterm>
@@ -172,109 +465,50 @@
</para>
</note>
-</sect2>
-
-<sect2 id="testslonystate">
-<title>test_slony_state</title>
-<indexterm><primary>script test_slony_state pour tester l'état de la réplication</primary></indexterm>
-
<para>
- Ce script effectue différents analyses sur l'état d'un cluster &slony1;.
+ Alternatively, Ismail Yenigul points out how he managed to
+ monitor slony using <application>MRTG</application> without installing
+ <application>SNMPD</application>.
</para>
<para>
- Vous devez spécifier les arguments tels que la <option>base de
- données</option>, l'<option>hôte</option>, l'<option>utilisateur</option>,
- le <option>cluster</option>, le <option>mot de passe</option> et le
- <option>port</option> afin de se connecter à n'importe quel nœud du
- cluster. Vous devez également préciser une commande <option>mailprog</option>
- (qui doit être une commande équivalente à la commande
- <productname>Unix</productname> <application>mailx</application>) et une
- destination pour le courrier.
+ Here is the mrtg configuration
</para>
-<para>
- Par ailleurs, vous spécifiez les paramètres de connexion aux bases de données
- via les variables d'environnement utilisées par
- <application>libpq</application>, <emphasis>par exemple</emphasis> :
- <envar>PGPORT</envar>, <envar>PGDATABASE</envar>, <envar>PGUSER</envar>,
- <envar>PGSERVICE</envar> et ainsi de suite.
-</para>
+<programlisting>
+Target[db_replication_lagtime]:`/bin/snmpReplicationLagTime.sh 2`
+MaxBytes[db_replication_lagtime]: 400000000
+Title[db_replication_lagtime]: db: replication lag time
+PageTop[db_replication_lagtime]: <H1>db: replication lag time</H1>
+Options[db_replication_lagtime]: gauge,nopercent,growright
+</programlisting>
<para>
- Le script se promène à travers <xref linkend="table.sl-path"/> pour trouver
- tous les nœuds du cluster et dans les DSNs qui lui permettront de se
- connecter à chaque nœud.
+ and here is the modified version of the script
</para>
-<para>
- Pour chaque nœud, le script examine l'état des données suivantes :
-</para>
+<programlisting>
+# cat /bin/snmpReplicationLagTime.sh
+#!/bin/bash
-<itemizedlist>
- <listitem>
- <para>
- Vérification de <xref linkend="table.sl-listen"/> à la recherche de
- problèmes <quote>déterminés analytiquement</quote>. Cela liste les voies
- de communication qui ne sont pas couvertes.
- </para>
- </listitem>
+output=`/usr/bin/psql -U slony -h 192.168.1.1 -d endersysecm -qAt -c
+"select cast(extract(epoch from st_lag_time) as int8) FROM _mycluster.sl_status WHERE st_received = $1"`
+echo $output
+echo $output
+echo
+echo
+# end of script#
+</programlisting>
- <listitem>
- <para>
- Effectuer un résumé des événements sur le nœud d'origine.
- </para>
- <para>
- Si un nœud n'a pas soumis un événement depuis longtemps, il y a
- certainement un problème.
- </para>
- </listitem>
+<note>
+ <para>
+ MRTG expects four lines from the script, and since there
+ are only two lines provided, the output must be padded to four
+ lines.
+ </para>
+</note>
- <listitem>
- <para>
- Vérification de <quote>l'âge</quote> de la table <xref
- linkend="table.sl-confirm"/>.
- </para>
-
- <para>
- Si un ou plusieurs nœuds du cluster n'ont pas envoyé de rapport
- récemment, alors cela peut conduire à l'absence de nettoyage dans
- certaines tables comme <xref linkend="table.sl-log-1"/> et <xref
- linkend="table.sl-seqlog"/>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Vérifications des transactions longues.
- </para>
-
- <para>
- Ceci ne fonctionne correctement que si le collecteur de statistique est
- configuré pour collecter les requêtes, c'est-à-dire l'option
- <option>stats_command_string = true</option> est présente dans
- <filename>postgresql.conf</filename>.
- </para>
-
- <para>
- Si des applications buggées conservent des connexions ouvertes, ce script
- devrait les trouver.
- </para>
-
- <para>
- Si des applications buggées conservent des connexions ouvertes, plusieurs
- effets négatifs sont à prévoir tels que <link
- linkend="longtxnsareevil">ceux décrits dans la FAQ</link>.
- </para>
- </listitem>
-</itemizedlist>
-
-<para>
- Ce script fait des diagnostiques basés sur des paramètres définis dans le
- script ; si vous n'aimez pas les valeurs par défaut, modifiez-les !
-</para>
-
</sect2>
<sect2 id="search-logs">
@@ -316,7 +550,12 @@
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>.
+ url="http://www.mediawiki.org/">MediaWiki</ulink>. Notons que l'option
+ <option>--categories</option> permet à l'utilisateur de préciser un ensemble
+ de catégories (séparées par une virgule) qui seront associées aux résultats.
+ Si vous avez passer l'option <option>--categories=slony1</option> à une série
+ de clusters &slony1;, cela entraînera la création d'une page catégorie
+ répertoriant l'ensemble des clusters &slony1;.
</para>
<para>
@@ -326,7 +565,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 > Slony_replication.wiki
+~/logtail.en> perl $SLONYHOME/tools/mkmediawiki.pl --host localhost --database slonyregress1 --cluster slony_regress1 --categories=Slony-I > Slony_replication.wiki
~/logtail.en> mvs commit -m "More sophisticated generated Slony-I cluster docs" Slony_replication.wiki
Doing commit Slony_replication.wiki with host: logtail and lang: en
</screen>
@@ -341,4 +580,125 @@
</sect2>
+<sect2>
+<title>Analysis of a SYNC</title>
+
+<para>
+ The following is (as of 2.0) an extract from the &lslon; log for node
+ #2 in a run of <quote>test1</quote> from the <xref linkend="testbed"/>.
+</para>
+
+<screen>
+DEBUG2 remoteWorkerThread_1: SYNC 19 processing
+INFO about to monitor_subscriber_query - pulling big actionid list 134885072
+INFO remoteWorkerThread_1: syncing set 1 with 4 table(s) from provider 1
+DEBUG2 ssy_action_list length: 0
+DEBUG2 remoteWorkerThread_1: current local log_status is 0
+DEBUG2 remoteWorkerThread_1_1: current remote log_status = 0
+DEBUG1 remoteHelperThread_1_1: 0.028 seconds delay for first row
+DEBUG1 remoteHelperThread_1_1: 0.978 seconds until close cursor
+INFO remoteHelperThread_1_1: inserts=144 updates=1084 deletes=0
+INFO remoteWorkerThread_1: sync_helper timing: pqexec (s/count)- provider 0.063/6 - subscriber 0.000/6
+INFO remoteWorkerThread_1: sync_helper timing: large tuples 0.315/288
+DEBUG2 remoteWorkerThread_1: cleanup
+INFO remoteWorkerThread_1: SYNC 19 done in 1.272 seconds
+INFO remoteWorkerThread_1: SYNC 19 sync_event timing: pqexec (s/count)- provider 0.001/1 - subscriber 0.004/1 - IUD 0.972/248
+</screen>
+
+<para>
+ Here are some notes to interpret this output:
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Note the line that indicates
+ <screen>inserts=144 updates=1084 deletes=0</screen>
+ </para>
+
+ <para>
+ This indicates how many tuples were affected by this particular SYNC.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Note the line indicating
+ <screen>0.028 seconds delay for first row</screen>
+ </para>
+
+ <para>
+ This indicates the time it took for the <screen>LOG
+ cursor</screen> to get to the point of processing the first row of
+ data. Normally, this takes a long time if the SYNC is a large one,
+ and one requiring sorting of a sizable result set.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Note the line indicating
+ <screen>0.978 seconds until close cursor</screen>
+ </para>
+
+ <para>
+ This indicates how long processing took against the provider.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para> sync_helper timing: large tuples 0.315/288 </para>
+
+ <para>
+ This breaks off, as a separate item, the number of large tuples
+ (<emphasis>e.g.</emphasis> - where size exceeded the configuration
+ parameter <xref linkend="slon-config-max-rowsize"/>) and where the
+ tuples had to be processed individually.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><screen>SYNC 19 done in 1.272 seconds</screen></para>
+
+ <para>
+ This indicates that it took 0.108 seconds, in total, to process
+ this set of SYNCs.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <screen>SYNC 19 sync_event timing: pqexec (s/count)- provider 0.001/1 - subscriber 0.004/0 - IUD 0.972/248</screen>
+ </para>
+
+ <para>
+ This records information about how many queries were issued
+ against providers and subscribers in function
+ <function>sync_event()</function>, and how long they took.
+ </para>
+
+ <para>
+ Note that 248 does not match against the numbers of inserts,
+ updates, and deletes, described earlier, as I/U/D requests are
+ clustered into groups of queries that are submitted via a single
+ <function>pqexec()</function> call on the
+ subscriber.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <screen>sync_helper timing: pqexec (s/count)- provider 0.063/6 - subscriber 0.000/6</screen>
+ </para>
+
+ <para>
+ This records information about how many queries were issued against
+ providers and subscribers in function <function>sync_helper()</function>,
+ and how long they took.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
</sect1>
Modified: traduc/trunk/slony/partitioning.xml
===================================================================
--- traduc/trunk/slony/partitioning.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/partitioning.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -152,8 +152,7 @@
</itemizedlist>
<para>
- Il existe plusieurs fonctions qui prennent en charge cela, pour les versions
- 8.1 et ultérieures de &postgres;. L'utilisateur
+ 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.
Modified: traduc/trunk/slony/releasechecklist.xml
===================================================================
--- traduc/trunk/slony/releasechecklist.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/releasechecklist.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -24,7 +24,7 @@
<listitem>
<para>
- Rédigez Un sorte de plan de test standard.
+ Rédigez une sorte de plan de test standard.
</para>
</listitem>
@@ -103,6 +103,11 @@
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>
@@ -110,6 +115,11 @@
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>
<listitem>
@@ -135,7 +145,7 @@
</listitem>
<listitem>
- <para>PACKAGE_STRING=postgresql-slony1-engine REL_1_1_2</para>
+ <para>PACKAGE_STRING=slony1 REL_1_1_2</para>
</listitem>
</itemizedlist>
@@ -184,6 +194,12 @@
<command> ./configure && make all && make clean</command>
mais c'est une approche quelque peu disgracieuse.
</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>
@@ -195,6 +211,13 @@
<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>
<listitem>
Modified: traduc/trunk/slony/reshape.xml
===================================================================
--- traduc/trunk/slony/reshape.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/reshape.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -63,8 +63,15 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ After performing the configuration change, you should, as <xref
+ linkend="bestpractices"/>, run the <eststate; scripts in order
+ to validate that the cluster state remains in good order after
+ this change.
+ </para>
+ </listitem>
</itemizedlist>
-
</para>
<para>
Modified: traduc/trunk/slony/slon.xml
===================================================================
--- traduc/trunk/slony/slon.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/slon.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -67,10 +67,13 @@
<para>
Les cinq premiers niveaux de débogage (de Fatal à Info) sont
- <emphasis>toujours</emphasis> affichés dans les traces. Si
- <envar>log_level</envar> est configuré à 2 (un choix routinier et,
- généralement, préférable), alors les messages de niveaux de
- débogage 1 et 2 seront aussi envoyés.
+ <emphasis>toujours</emphasis> affichés dans les traces. Dans les
+ premières versions de &slony1;, le niveau des traces
+ <quote>suggéré</quote> était 2, ce qui affichait tous les messages
+ jusqu'au niveau Debug2. Avec &slony1; version 2, il est recommandé
+ de positionner <envar>log_level</envar> à 0 ; la plupart des
+ informations intéressantes sont produites à des niveaux supérieurs
+ à celui-là.
</para>
</listitem>
</varlistentry>
Modified: traduc/trunk/slony/slonconf.xml
===================================================================
--- traduc/trunk/slony/slonconf.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/slonconf.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -102,11 +102,17 @@
<listitem>
<para>Niveau de traces de débogage (plus la valeur est haute, plus les
messages sont verbeux).
- Valeurs possibles : de 0 à 4. Valeur par défaut : 2.</para>
+ Valeurs possibles : de 0 à 4. Valeur par défaut : 0.</para>
<para>Il y a <link linkend="nineloglevels">neuf niveaux de messages
de trace</link> ; en utilisant cette option, une partie ou l'ensemble
- des niveaux <quote>debug</quote> peut être désactivé.</para>
+ des niveaux <quote>debug</quote> peut être désactivé.
+ Avec &slony1; version 2, beaucoup de niveaux de message ont
+ été révisé afin que des <quote>informations intéressantes</quote>
+ apparaissent à partir des niveaux CONFIG/INFO, et qu'il soit possible
+ de fonctionner au niveau 0, en ignorant tous les messages
+ <quote>DEBUG</quote> et continuer à recevoir des informations
+ utiles dans les journaux applicatifs.</para>
</listitem>
</varlistentry>
@@ -291,6 +297,15 @@
<para>Fréquence maximale (en millisecondes) de vérification des mises à jour.
Valeurs possibles : de 10 à 60000, La valeur par défaut est 100.
</para>
+
+ <para>
+ This parameter is primarily of concern on nodes that
+ originate replication sets. On a non-origin node, there
+ will never be update activity that would induce a SYNC;
+ instead, the timeout value described below will induce a
+ SYNC every so often <emphasis>despite absence of changes to
+ replicate</emphasis>.
+ </para>
</listitem>
</varlistentry>
@@ -321,6 +336,50 @@
<envar>sync_interval_timeout</envar>.
Valeurs possibles : [0-120000]. Valeur par défaut : 1000.
</para>
+
+ <para>
+ This parameter is likely to be primarily of concern on
+ nodes that originate replication sets, though it does affect
+ how often events are generated on other nodes.
+ </para>
+
+ <para>
+ On a non-origin node, there never is activity to cause a
+ SYNC to get generated; as a result, there will be a SYNC
+ generated every <envar>sync_interval_timeout</envar>
+ milliseconds. There are no subscribers looking for those
+ SYNCs, so these events do not lead to any replication
+ activity. They will, however, clutter sl_event up a little,
+ so it would be undesirable for this timeout value to be set
+ too terribly low. 120000ms represents 2 minutes, which is
+ not a terrible value.
+ </para>
+
+ <para>
+ The two values function together in varying ways:
+ </para>
+
+ <para>
+ On an origin node, <envar>sync_interval</envar> is
+ the <emphasis>minimum</emphasis> time period that will be
+ covered by a SYNC, and during periods of heavy application
+ activity, it may be that a SYNC is being generated
+ every <envar>sync_interval</envar> milliseconds.
+ </para>
+
+ <para>
+ On that same origin node, there may be quiet intervals,
+ when no replicatable changes are being submitted. A SYNC will
+ be induced, anyways,
+ every <envar>sync_interval_timeout</envar>
+ milliseconds.
+ </para>
+
+ <para>
+ On a subscriber node that does not originate any sets,
+ only the <quote>timeout-induced</quote> SYNCs will
+ occur.
+ </para>
</listitem>
</varlistentry>
@@ -332,14 +391,18 @@
</term>
<listitem>
<para>
- Nombre maximum d'événements <command>SYNC</command> qui seront regroupés
- ensemble lorsqu'un nœud abonné tombe en panne.
- Les événements <command>SYNC</command>s ne sont empaquetés
- que s'ils sont nombreux et qu'ils sont contiguës.
- S'il n'y qu'un seul événement <command>SYNC</command> disponible,
- même l'option <option>-g60</option> s'appliquera à cet évènement unique.
- Dès qu'un nœud abonné rattrape son retard, il appliquera chaque événement
- <command>SYNC</command> individuellement.
+ Maximum number of <command>SYNC</command> events that a
+ subscriber node will group together when/if a subscriber
+ falls behind. <command>SYNC</command>s are batched only if
+ there are that many available and if they are
+ contiguous. Every other event type in between leads to a
+ smaller batch. And if there is only
+ one <command>SYNC</command> available, even though you used
+ <option>-g600</option>, the &lslon; will apply just the one
+ that is available. As soon as a subscriber catches up, it
+ will tend to apply each
+ <command>SYNC</command> by itself, as a singleton, unless
+ processing should fall behind for some reason.
Valeurs possibles : [0,10000]. Valeur par défaut : 20.
</para>
</listitem>
@@ -361,6 +424,37 @@
</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-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/slonik_ref.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -410,6 +410,13 @@
<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>
@@ -449,7 +456,11 @@
<variablelist>
<varlistentry><term><literal>ID = ival</literal></term>
- <listitem><para>L'identifiant numérique et unique du nouveau nœud.</para></listitem>
+ <listitem><para>L'identifiant numérique et unique du nouveau nœud.</para>
+ <para> Note that the ID is <emphasis>immutable</emphasis>
+ because it is used as the basis for inter-node event
+ communications. </para>
+ </listitem>
</varlistentry>
<varlistentry><term><literal> COMMENT = 'description' </literal></term>
@@ -462,14 +473,20 @@
<listitem><para>Spécifie qu'un nœud est un nœud virtuel de récupération
pour l'archivage de journaux de réplication. Si ce paramètre est à true,
<application>slonik</application> n'essaiera pas d'initialiser la base de
- donnée avec le schéma de réplication.</para></listitem>
+ donnée avec le schéma de réplication.</para>
+
+ <warning><para> Never use the SPOOLNODE value - no released
+ version of &slony1; has ever behaved in the fashion described
+ in the preceding fashion. Log shipping, as it finally emerged
+ in 1.2.11, does not require initializing <quote>spool
+ nodes</quote>.</para> </warning></listitem>
</varlistentry>
<varlistentry><term><literal>EVENT NODE = ival</literal></term>
<listitem><para>L'identifiant du nœud utilisé pour créer l'événement de configuration,
qui prévient tous les nœuds existants de l'arrivée du nouveau nœud.
- La valeur par défaut est 1.</para></listitem>
+ </para></listitem>
</varlistentry>
</variablelist>
</para>
@@ -493,7 +510,10 @@
<para>Cette commande fut introduite dans &slony1; 1.0. Le paramètre <envar>SPOOLNODE</envar>
fut introduit dans la version 1.1 mais n'était pas implémentée dans cette version.
La fonctionnalité <envar>SPOOLNODE</envar> est arrivée dans la
- version 1.2.</para>
+ version 1.2, but <envar>SPOOLNODE</envar> was not used
+ for this purpose. In later versions, hopefully
+ <envar>SPOOLNODE</envar> will be unavailable. </para>
+ <para> In version 2.0, the default value for <envar>EVENT NODE</envar> was removed, so a node must be specified.</para>
</refsect1>
</refentry>
@@ -524,7 +544,7 @@
<listitem><para>L'identifiant du nœud à supprimer.</para></listitem>
</varlistentry>
<varlistentry><term><literal> EVENT NODE = ival </literal></term>
- <listitem><para>L'identifiant du nœud qui génère l'événement. La valeur par défaut est 1.
+ <listitem><para>L'identifiant du nœud qui génère l'événement.
</para></listitem>
</varlistentry>
</variablelist>
@@ -565,6 +585,7 @@
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ <para> In version 2.0, the default value for <envar>EVENT NODE</envar> was removed, so a node must be specified.</para>
</refsect1>
</refentry>
@@ -641,13 +662,14 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>RESTART NODE (options);</command>
+ <command>RESTART NODE options;</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para> Provoque l'arrêt et le redémarrage d'un démon
+ (processus <application>slon</application>)
de réplication sur le nœud spécifié.
Théoriquement, cette commande est obsolète. En pratique,
les délais TCP peuvent retarder les changements critiques
@@ -673,8 +695,10 @@
<para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
</refsect1>
<refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0 ;
- Elle ne devrait plus être nécessaire à partir de la version 1.0.5.</para>
+ <para>Cette commande fut introduite dans &slony1; 1.0 ; frequent use became unnecessary as
+ of version 1.0.5. There are, however, occasional cases where it is
+ necessary to interrupt a <application>slon</application> process,
+ and this allows this to be scripted via slonik.</para>
</refsect1>
</refentry>
@@ -963,7 +987,8 @@
</para>
<para>
- En dernier recours, cette commande peut être utilisée pour ajouter
+ En dernier recours, <emphasis>dans les versions de &slony1; antérieures
+ à la 2.0</emphasis>, cette commande peut être utilisée pour ajouter
un attribut à une table qui ne possède par de clef primaire.
Sachant que cette modification peut avoir des effets secondaires
indésirables, <emphasis>il est très fortement recommandé que les
@@ -971,6 +996,12 @@
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
@@ -1037,6 +1068,16 @@
</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>
@@ -1199,7 +1240,7 @@
<listitem><para>Identifiant unique de l'ensemble qui contiendra les deux ensembles distincts.</para></listitem>
</varlistentry>
<varlistentry><term><literal>ADD ID = ival</literal></term>
- <listitem><para>Identifiant unique de l'ensemble de l'ensemble dont les objets vont être transférés.</para></listitem>
+ <listitem><para>Identifiant unique de l'ensemble de l'ensemble dont les objets vont être transférés dans l'ensemble ci-dessus.</para></listitem>
</varlistentry>
<varlistentry><term><literal>ORIGIN = ival</literal></term>
<listitem><para>Nœud d'origine actuel des deux ensembles.</para></listitem>
@@ -1271,8 +1312,8 @@
<listitem><para>Identifiant de l'ensemble dans lequel la table doit être ajoutée.</para></listitem>
</varlistentry>
<varlistentry><term><literal>ORIGIN = ival</literal></term>
- <listitem><para>Nœud origine de l'ensemble. Les prochaines versions de <application>slonik</application>
- devraient pouvoir deviner cette information.</para></listitem>
+ <listitem><para>Nœud origine de l'ensemble. Nous pourrions imaginer une prochaine version de <application>slonik</application>
+ en devinant cette information par lui-même, mais il y a des race conditions.</para></listitem>
</varlistentry>
<varlistentry><term><literal>ID = ival</literal></term>
@@ -1286,7 +1327,17 @@
<para>Cet identifiant doit être unique pour tous les ensembles de réplication ;
vous ne devez pas avoir deux tables du même cluster avec le même identifiant.
- </para></listitem>
+ </para>
+
+ <para> Note that &slony1; generates an in-memory array
+ indicating all of the fully qualified table names; if you use
+ large table ID numbers, the sparsely-utilized array can lead
+ to substantial wastage of memory. Each potential table ID
+ consumes a pointer to a char, commonly costing 4 bytes per
+ table ID on 32 bit architectures, and 8 bytes per table ID on
+ 64 bit architectures. </para>
+
+ </listitem>
</varlistentry>
<varlistentry><term><literal>FULLY QUALIFIED NAME = 'string'</literal></term>
<listitem><para>Le nom complet de la table tel que décrit dans
@@ -1376,8 +1427,10 @@
<varlistentry><term><literal>Slony-I: cannot add table to currently subscribed set 1</literal></term>
<listitem><para>&slony1; ne peut pas ajouter des tables dans un ensemble qui est
- en cours de réplication. Pour contourner ce problème, vous devez définir un nouvel ensemble
- qui contiendra les nouvelles tables.</para> </listitem> </varlistentry>
+ en cours de réplication. Instead, you need to define a new replication set, and add any
+ new tables to <emphasis>that</emphasis> set. You might then
+ use <xref linkend="stmtmergeset"/> to merge the new set into an
+ existing one, if that seems appropriate.</para> </listitem> </varlistentry>
</variablelist>
@@ -1751,6 +1804,17 @@
</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>
@@ -1765,12 +1829,15 @@
<para>Cette opération pose brièvement un verrou exclusif sur la table spécifiée
sur chaque nœud auquel elle s'applique, afin de modifier le schéma de la table
-et y ajouter de nouveau le trigger.
+et y ajouter de nouveau le trigger, mais (heureusement) très brièvement.
</para>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ <para>Avec &slony1; version 2.0, cette commande est supprimée car
+obsolète. En effet, les triggers ne sont plus <quote>trafiqués</quote>
+dans le catalogue système.</para>
</refsect1>
</refentry>
@@ -1836,6 +1903,10 @@
</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>
@@ -1960,7 +2031,10 @@
<listitem><para>Indique si le nouvel abonné doit stocker les logs
pendant la réplication afin de pouvoir devenir fournisseur pour de futurs
-nœuds.</para></listitem>
+nœuds. Any
+ node that is intended to be a candidate for FAILOVER
+ <emphasis>must</emphasis> have <command>FORWARD =
+ yes</command>.</para></listitem>
</varlistentry>
</variablelist>
@@ -2432,6 +2506,7 @@
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ <para> In version 2.0, the default <envar>BACKUP NODE</envar> value of 1 was removed, so it is mandatory to provide a value for this parameter.</para>
</refsect1>
</refentry>
@@ -2485,13 +2560,13 @@
</varlistentry>
<varlistentry><term><literal>EVENT NODE = ival</literal></term>
- <listitem><para>(Optionnel) L'identifiant de l'origine courante de l'ensemble. La valeur par défaut est 1.</para></listitem>
+ <listitem><para>(Obligatoire) L'identifiant de l'origine courante de l'ensemble. La valeur par défaut est 1.</para></listitem>
</varlistentry>
<varlistentry><term><literal>EXECUTE ONLY ON = ival</literal></term>
<listitem><para>(Optionnel) L'identifiant du seul nœud qui
-doit exécuter le script. Cette option implique que le script sera propagé, par <xref linkend="slonik"/>,
- <emphasis>seulement</emphasis> sur le seul nœud spécifié.
+doit exécuter le script. Cette option implique que le script sera propagé
+sur tous les nœuds mais exécuté sur un seul.
Par défaut, on exécute le script sur tous les nœuds abonnés à l'ensemble de réplication.
</para></listitem>
@@ -2503,15 +2578,15 @@
<para>Notons qu'il s'agit d'une opération &rlocking;, ce qui signifie qu'elle peut être
bloquée par l'activité d'une autre base.</para>
- <para>Au démarrage de cet événement, toutes les tables répliquées sont
+ <para>In versions up to (and including) the 1.2 branch, au démarrage de cet événement, toutes les tables répliquées sont
déverrouillées par la fonction <function>alterTableRestore(tab_id)</function>.
Une fois le script SQL exécuté, elles sont remises en <quote>mode réplication
</quote> avec <function>alterTableForReplication(tab_id)</function>.
Cela implique que toutes les tables sont verrouillées par ce processus
&slon; pendant la durée du script SQL.</para>
- <para>Si les colonnes d'une table sont modifiées, il est très
-important que les triggers soient régénérés, sinon ils peuvent
+ <para>Si les colonnes d'une table sont modifiées, il est essentiel que les triggers soient régénérés (<emphasis>e.g.</emphasis> - by
+ <function>alterTableForReplication(tab_id)</function>), sinon les attributes in the <function>logtrigger()</function> trigger peuvent
être inadaptés à la nouvelle forme du schéma.
</para>
@@ -2527,14 +2602,14 @@
<programlisting>
EXECUTE SCRIPT (
SET ID = 1,
- FILENAME = '/tmp/changes_2004-05-01.sql',
+ FILENAME = '/tmp/changes_2008-04-01.sql',
EVENT NODE = 1
);
</programlisting>
</refsect1>
<refsect1> <title>Utilisation de verrous</title>
- <para>Un verrou exclusif est posé
+ <para>Sur les versions antérieures à la branche 2.0, un verrou exclusif est posé
sur chaque table répliquée sur le nœud origine, afin de retirer les triggers
de réplication. Une fois le script DDL achevé, ces verrous sont enlevés.
</para>
@@ -2544,6 +2619,13 @@
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>
@@ -2574,6 +2656,9 @@
que les triggers sont retirés au départ et restaurés à la fin).
Ceci couvre les risques lorsqu'on lance une requête de changements DDL
sur des tables appartenant à plusieurs ensemble de réplication.</para>
+ <para> In version 2.0, the default value for <envar>EVENT
+ NODE</envar> was removed, so a node must be specified.</para>
+
</refsect1>
</refentry>
@@ -2672,8 +2757,8 @@
<command>CREATE SET</command>) soient traités sur un autre nœud avant de
lancer d'autres commandes (par exemple <xref linkend="stmtsubscribeset"/>).
<command>WAIT FOR EVENT</command> peut être utilisé pour demander à un
-script <application>slonik</application> d'attendre jusqu'à ce que le nœud abonné
-soit prêt pour l'action suivante.
+script <application>slonik</application> d'attendre for confirmation of an event, which hopefully means that
+ the the next action.
</para>
<para><command>WAIT FOR EVENT</command> doit être appelée en dehors d'un
@@ -2694,7 +2779,7 @@
</varlistentry>
<varlistentry><term><literal>WAIT ON = ival</literal></term>
<listitem><para>L'identifiant du nœud où la table &slconfirm; est vérifiée.
-La valeur par défaut est 1.</para></listitem>
+</para></listitem>
</varlistentry>
<varlistentry><term><literal>TIMEOUT = ival</literal></term>
@@ -2722,6 +2807,10 @@
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
+
+ <para> In version 2.0, the default value for <envar>WAIT ON</envar>
+ was removed, so a node must be specified.</para>
+
</refsect1>
<refsect1> <title>Bizarreries</title>
@@ -2744,11 +2833,11 @@
<programlisting>
# Supposons que l'ensemble 1 a deux abonnés direct 2 et 3
SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 2);
- SYNC (ID=1);
- WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 2, WAIT ON=1);
+ WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = ALL, WAIT ON=1);
SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 3);
+ WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = ALL, WAIT ON=1);
SYNC (ID=1);
- WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 3, WAIT ON=1);
+ WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = ALL, WAIT ON=1);
MERGE SET ( ID = 1, ADD ID = 999, ORIGIN = 1 );
</programlisting>
</refsect1>
@@ -2885,5 +2974,82 @@
</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-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/slony.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -50,12 +50,23 @@
<!ENTITY slnode "<xref linkend='table.sl-node'/>">
<!ENTITY sllog1 "<xref linkend='table.sl-log-1'/>">
<!ENTITY sllog2 "<xref linkend='table.sl-log-2'/>">
+ <!ENTITY slseqlog "<xref linkend='table.sl-seqlog'/>">
<!ENTITY slconfirm "<xref linkend='table.sl-confirm'/>">
+ <!ENTITY slevent "<xref linkend='table.sl-event'/>">
+ <!ENTITY slnode "<xref linkend='table.sl-node'/>">
+ <!ENTITY slpath "<xref linkend='table.sl-path'/>">
+ <!ENTITY sllisten "<xref linkend='table.sl-listen'/>">
+ <!ENTITY slregistry "<xref linkend='table.sl-registry'/>">
+ <!ENTITY slsetsync "<xref linkend='table.sl-setsync'/>">
+ <!ENTITY slsubscribe "<xref linkend='table.sl-subscribe'/>">
+ <!ENTITY sltable "<xref linkend='table.sl-table'/>">
+ <!ENTITY slset "<xref linkend='table.sl-set'/>">
<!ENTITY rplainpaths "<xref linkend='plainpaths'/>">
<!ENTITY rlistenpaths "<xref linkend='listenpaths'/>">
<!ENTITY pglistener "<envar>pg_listener</envar>">
<!ENTITY lslon "<xref linkend='slon'/>">
<!ENTITY lslonik "<xref linkend='slonik'/>">
+ <!ENTITY lteststate "<xref linkend='testslonystate'/>">
<!ENTITY lfrenchtranslation "<xref linkend='frenchtranslation'/>">
]>
@@ -101,7 +112,9 @@
&failover;
&listenpaths;
&plainpaths;
+ &triggers;
&locking;
+ &raceconditions;
&addthings;
&dropthings;
&logshipfile;
@@ -114,6 +127,8 @@
&testbed;
&loganalysis;
&help;
+ &supportedplatforms;
+ &releasechecklist;
</article>
@@ -144,9 +159,6 @@
</part>
-
- &supportedplatforms;
- &releasechecklist;
&schemadoc;
<!-- &bookindex; -->
Modified: traduc/trunk/slony/slonyupgrade.xml
===================================================================
--- traduc/trunk/slony/slonyupgrade.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/slonyupgrade.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -132,4 +132,250 @@
</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-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/subscribenodes.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -122,7 +122,7 @@
voir une erreur similaire celle-ci :
</para>
- <screen>2005-04-13 07:11:28 PDT ERROR remoteWorkerThread_11: "declare LOG
+ <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
Modified: traduc/trunk/slony/supportedplatforms.xml
===================================================================
--- traduc/trunk/slony/supportedplatforms.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/supportedplatforms.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -14,7 +14,7 @@
sur ces plate-formes.
</para>
-<para>Dernière mise à jour : 17 novembre 2006</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,
@@ -147,33 +147,6 @@
</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-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/testbed.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -226,6 +226,19 @@
</glossentry>
<glossentry>
+ <glossterm><envar>TMPDIR</envar></glossterm>
+
+ <glossdef>
+ <para>
+ By default, the tests will generate their output in
+ <filename>/tmp</filename>, <filename>/usr/tmp</filename>, or
+ <filename>/var/tmp</filename>, unless you set your own value for this
+ environment variable.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
<glossterm><envar>SLTOOLDIR</envar></glossterm>
<glossdef>
@@ -264,6 +277,63 @@
</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-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/usingslonik.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -149,14 +149,6 @@
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,
@@ -170,7 +162,7 @@
comment = 'Table tellers');
set add table (set id = 1, origin = 1,
id = 4, fully qualified name = 'public.history',
- key = serial, comment = 'Table accounts');
+ comment = 'Table accounts');
}
on error {
exit 1;
@@ -213,12 +205,6 @@
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,
@@ -232,7 +218,7 @@
comment = 'Table tellers');
set add table (set id = $mainset, origin = $origin,
id = 4, fully qualified name = 'public.history',
- key = serial, comment = 'Table accounts');
+ comment = 'Table accounts');
} on error {
exit 1;
}
@@ -264,12 +250,6 @@
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
Modified: traduc/trunk/slony/version.xml
===================================================================
--- traduc/trunk/slony/version.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/version.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -1,2 +1,2 @@
-<!ENTITY version "1.2.15">
-<!ENTITY majorversion "1.2">
+<!ENTITY version "2.0.0">
+<!ENTITY majorversion "2.0">
Modified: traduc/trunk/slony/versionupgrade.xml
===================================================================
--- traduc/trunk/slony/versionupgrade.xml 2009-02-23 15:49:05 UTC (rev 1247)
+++ traduc/trunk/slony/versionupgrade.xml 2009-02-23 15:50:16 UTC (rev 1248)
@@ -56,20 +56,22 @@
</para>
<para>
- Notez que cette opération a provoqué une coupure de service de 40 heures.
+ Notez que cette approche 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
+ par une autre de quelques secondes au minimum. L'approche requise
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.
+ &postgres;. Il est possible que cela prenne bien plus de 40 heures pour
+ créer ce réplicat. Néanmoins sa création ne nécessite aucun arrêt de
+ production et, 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 :
+ Au moment de basculer vers la nouvelle base de données, la portion de
+ procédure qui requiert un arrêt de production est beaucoup moins
+ longue :
<itemizedlist>
<listitem>
@@ -81,7 +83,7 @@
<listitem>
<para>
- Verrouillez le set contre les lectures des applications clientes en
+ Verrouillez l'ensemble contre les lectures des applications clientes en
utilisant <xref linkend="stmtlockset"/> ;
</para>
</listitem>
@@ -103,11 +105,12 @@
</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.
+ This procedure should only need to take a very short time,
+ likely based more on how much time is required to reconfigure your
+ applications than anything else. If you can automate all of these
+ steps, the outage may conceivably be a second or less. If manual
+ handling is necessary, then it is likely to take somewhere between a
+ few seconds and a few minutes.
</para>
<para>
@@ -145,6 +148,13 @@
Ainsi, vous avez <emphasis>trois</emphasis> nœuds, un avec la
nouvelle version de &postgres;, et deux autres avec l'ancienne version.
</para>
+
+ <para>
+ Note that this imposes a need to have &slony1; built against
+ <emphasis>both</emphasis> databases (<emphasis>e.g.</emphasis> - at
+ the very least, the binaries for the stored procedures need to have
+ been compiled against both versions of &postgres;).
+ </para>
</listitem>
<listitem>
@@ -205,11 +215,428 @@
&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;
+ <productname>eRServer</productname>. &postgres; 7.2 ne sera
+ <emphasis>jamais</emphasis> supportée par une version officielle de
+ &slony1;.
</para>
</note>
+<sect2>
+<title>Example: Upgrading a single database with no existing replication </title>
+
+<para>This example shows names, IP addresses, ports, etc to describe
+in detail what is going on</para>
+
+ <sect3>
+ <title>The Environment</title>
+ <programlisting>
+ Database machine:
+ name = rome
+ ip = 192.168.1.23
+ OS: Ubuntu 6.06 LTS
+ postgres user = postgres, group postgres
+
+ Current PostgreSQL
+ Version = 8.2.3
+ Port 5432
+ Installed at: /data/pgsql-8.2.3
+ Data directory: /data/pgsql-8.2.3/data
+ Database to be moved: mydb
+
+ New PostgreSQL installation
+ Version = 8.3.3
+ Port 5433
+ Installed at: /data/pgsql-8.3.3
+ Data directory: /data/pgsql-8.3.3/data
+
+ Slony Version to be used = 1.2.14
+ </programlisting>
+ </sect3>
+ <sect3>
+ <title>Installing &slony1;</title>
+
+ <para>
+ How to install &slony1; is covered quite well in other parts of
+ the documentation (<xref linkend="installation"/>); we will just
+ provide a quick guide here.</para>
+
+ <programlisting>
+ wget http://main.slony.info/downloads/1.2/source/slony1-1.2.14.tar.bz2
+ </programlisting>
+
+ <para> Unpack and build as root with</para>
+ <programlisting>
+ tar xjf slony1-1.2.14.tar.bz2
+ cd slony1-1.2.14
+ ./configure --prefix=/data/pgsql-8.2.3 --with-perltools=/data/pgsql-8.2.3/slony --with-pgconfigdir=/data/pgsql-8.2.3/bin
+ make clean
+ make
+ make install
+ chown -R postgres:postgres /data/pgsq-8.2.3
+ mkdir /var/log/slony
+ chown -R postgres:postgres /var/log/slony
+ </programlisting>
+
+ <para> Then repeat this for the 8.3.3 build. A very important
+ step is the <command>make clean</command>; it is not so
+ important the first time, but when building the second time, it
+ is essential to clean out the old binaries, otherwise the
+ binaries will not match the &postgres; 8.3.3 build with the
+ result that &slony1; will not work there. </para>
+
+ </sect3>
+ <sect3>
+ <title>Creating the slon_tools.conf</title>
+
+ <para>
+ The slon_tools.conf is <emphasis>the</emphasis> configuration
+ file. It contain all all the configuration information such as:
+
+ <orderedlist>
+ <listitem>
+ <para>All the nodes and their details (IPs, ports, db, user,
+ password)</para>
+ </listitem>
+ <listitem>
+ <para>All the tables to be replicated</para>
+ </listitem>
+ <listitem>
+ <para>All the sequences to be replicated</para>
+ </listitem>
+ <listitem>
+ <para> How the tables and sequences are arranged in sets</para>
+ </listitem>
+ </orderedlist>
+ </para>
+ <para> Make a copy of
+ <filename>/data/pgsql-8.2.3/etc/slon_tools.conf-sample</filename>
+ to <filename>slon_tools.conf</filename> and open it. The comments
+ in this file are fairly self explanatory. Since this is a one time
+ replication you will generally not need to split into multiple
+ sets. On a production machine running with 500 tables and 100
+ sequences, putting them all in a single set has worked fine.</para>
+
+ <orderedlist>
+ <para>A few modifications to do:</para>
+ <listitem>
+ <para> In our case we only need 2 nodes so delete the <command>add_node</command>
+ for 3 and 4.</para>
+ </listitem>
+ <listitem>
+ <para> <envar>pkeyedtables</envar> entry need to be updated with your tables that
+ have a primary key. If your tables are spread across multiple
+ schemas, then you need to qualify the table name with the schema
+ (schema.tablename)</para>
+ </listitem>
+ <listitem>
+ <para> <envar>keyedtables</envar> entries need to be updated
+ with any tables that match the comment (with good schema
+ design, there should not be any).
+ </para>
+ </listitem>
+ <listitem>
+ <para> <envar>serialtables</envar> (if you have any; as it says, it is wise to avoid this).</para>
+ </listitem>
+ <listitem>
+ <para> <envar>sequences</envar> needs to be updated with your sequences.
+ </para>
+ </listitem>
+ <listitem>
+ <para>Remove the whole set2 entry (as we are only using set1)</para>
+ </listitem>
+ </orderedlist>
+ <para>
+ This is what it look like with all comments stripped out:
+ <programlisting>
+$CLUSTER_NAME = 'replication';
+$LOGDIR = '/var/log/slony';
+$MASTERNODE = 1;
+
+ add_node(node => 1,
+ host => 'rome',
+ dbname => 'mydb',
+ port => 5432,
+ user => 'postgres',
+ password => '');
+
+ add_node(node => 2,
+ host => 'rome',
+ dbname => 'mydb',
+ port => 5433,
+ user => 'postgres',
+ password => '');
+
+$SLONY_SETS = {
+ "set1" => {
+ "set_id" => 1,
+ "table_id" => 1,
+ "sequence_id" => 1,
+ "pkeyedtables" => [
+ 'mytable1',
+ 'mytable2',
+ 'otherschema.mytable3',
+ 'otherschema.mytable4',
+ 'otherschema.mytable5',
+ 'mytable6',
+ 'mytable7',
+ 'mytable8',
+ ],
+
+ "sequences" => [
+ 'mytable1_sequence1',
+ 'mytable1_sequence2',
+ 'otherschema.mytable3_sequence1',
+ 'mytable6_sequence1',
+ 'mytable7_sequence1',
+ 'mytable7_sequence2',
+ ],
+ },
+
+};
+
+1;
+ </programlisting>
+ </para>
+ <para> As can be seen this database is pretty small with only 8
+ tables and 6 sequences. Now copy your
+ <filename>slon_tools.conf</filename> into
+ <filename>/data/pgsql-8.2.3/etc/</filename> and
+ <filename>/data/pgsql-8.3.3/etc/</filename>
+ </para>
+ </sect3>
+ <sect3>
+ <title>Preparing the new &postgres; instance</title>
+ <para> You now have a fresh second instance of &postgres; running on
+ port 5433 on the same machine. Now is time to prepare to
+ receive &slony1; replication data.</para>
+ <orderedlist>
+ <listitem>
+ <para>Slony does not replicate roles, so first create all the
+ users on the new instance so it is identical in terms of
+ roles/groups</para>
+ </listitem>
+ <listitem>
+ <para>
+ Create your db in the same encoding as original db, in my case
+ UTF8
+ <command>/data/pgsql-8.3.3/bin/createdb
+ -E UNICODE -p5433 mydb</command>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ &slony1; replicates data, not schemas, so take a dump of your schema
+ <command>/data/pgsql-8.2.3/bin/pg_dump
+ -s mydb > /tmp/mydb.schema</command>
+ and then import it on the new instance.
+ <command>cat /tmp/mydb.schema | /data/pgsql-8.3.3/bin/psql -p5433
+ mydb</command>
+ </para>
+ </listitem>
+ </orderedlist>
+
+ <para>The new database is now ready to start receiving replication
+ data</para>
+
+ </sect3>
+ <sect3>
+ <title>Initiating &slony1; Replication</title>
+ <para>This is the point where we start changing your current
+ production database by adding a new schema to it that contains
+ all the &slony1; replication information</para>
+ <para>The first thing to do is to initialize the &slony1;
+ schema. Do the following as, in the example, the postgres user.</para>
+ <note>
+ <para> All commands starting with <command>slonik</command> does not do anything
+ themself they only generate command output that can be interpreted
+ by the slonik binary. So issuing any of the scripts starting with
+ slonik_ will not do anything to your database. Also by default the
+ slonik_ scripts will look for your slon_tools.conf in your etc
+ directory of the postgresSQL directory. In my case
+ <filename>/data/pgsql-8.x.x/etc</filename> depending on which you are working on.</para>
+ </note>
+ <para>
+ <command>/data/pgsql-8.2.3/slony/slonik_init_cluster
+ > /tmp/init.txt</command>
+ </para>
+ <para>open /tmp/init.txt and it should look like something like
+ this</para>
+ <programlisting>
+# INIT CLUSTER
+cluster name = replication;
+ node 1 admin conninfo='host=rome dbname=mydb user=postgres port=5432';
+ node 2 admin conninfo='host=rome dbname=mydb user=postgres port=5433';
+ init cluster (id = 1, comment = 'Node 1 - mydb at rome');
+
+# STORE NODE
+ store node (id = 2, event node = 1, comment = 'Node 2 - mydb at rome');
+ echo 'Set up replication nodes';
+
+# STORE PATH
+ echo 'Next: configure paths for each node/origin';
+ store path (server = 1, client = 2, conninfo = 'host=rome dbname=mydb user=postgres port=5432');
+ store path (server = 2, client = 1, conninfo = 'host=rome dbname=mydb user=postgres port=5433');
+ echo 'Replication nodes prepared';
+ echo 'Please start a slon replication daemon for each node';
+
+ </programlisting>
+ <para>The first section indicates node information and the
+ initialization of the cluster, then it adds the second node to the
+ cluster and finally stores communications paths for both nodes in
+ the slony schema.</para>
+ <para>
+ Now is time to execute the command:
+ <command>cat /tmp/init.txt | /data/pgsql-8.2.3/bin/slonik</command>
+ </para>
+ <para>This will run pretty quickly and give you some output to
+ indicate success.</para>
+ <para>
+ If things do fail, the most likely reasons would be database
+ permissions, <filename>pg_hba.conf</filename> settings, or typos
+ in <filename>slon_tools.conf</filename>. Look over your problem
+ and solve it. If slony schemas were created but it still failed
+ you can issue the script <command>slonik_uninstall_nodes</command> to
+ clean things up. In the worst case you may connect to each
+ database and issue <command>drop schema _replication cascade;</command>
+ to clean up.
+ </para>
+ </sect3>
+ <sect3>
+ <title>The slon daemon</title>
+
+ <para>As the result from the last command told us, we should now
+ be starting a slon replication daemon for each node! The slon
+ daemon is what makes the replication work. All transfers and all
+ work is done by the slon daemon. One is needed for each node. So
+ in our case we need one for the 8.2.3 installation and one for the
+ 8.3.3.</para>
+
+ <para> to start one for 8.2.3 you would do:
+ <command>/data/pgsql-8.2.3/slony/slon_start 1 --nowatchdog</command>
+ This would start the daemon for node 1, the --nowatchdog since we
+ are running a very small replication we do not need any watchdogs
+ that keep an eye on the slon process if it stays up etc. </para>
+
+ <para>if it says started successfully have a look in the log file
+ at /var/log/slony/slony1/node1/ It will show that the process was
+ started ok</para>
+
+ <para> We need to start one for 8.3.3 as well. <command>
+ <command>/data/pgsql-8.3.3/slony/slon_start 2 --nowatchdog</command>
+ </command> </para>
+
+ <para>If it says it started successfully have a look in the log
+ file at /var/log/slony/slony1/node2/ It will show that the process
+ was started ok</para>
+ </sect3>
+ <sect3>
+ <title>Adding the replication set</title>
+ <para>We now need to let the slon replication know which tables and
+ sequences it is to replicate. We need to create the set.</para>
+ <para>
+ Issue the following:
+ <command>/data/pgsql-8.2.3/slony/slonik_create_set
+ set1 > /tmp/createset.txt</command>
+ </para>
+
+ <para> <filename> /tmp/createset.txt</filename> may be quite lengthy depending on how
+ many tables; in any case, take a quick look and it should make sense as it
+ defines all the tables and sequences to be replicated</para>
+
+ <para>
+ If you are happy with the result send the file to the slonik for
+ execution
+ <command>cat /tmp/createset.txt | /data/pgsql-8.2.3/bin/slonik
+ </command>
+ You will see quite a lot rolling by, one entry for each table.
+ </para>
+ <para>You now have defined what is to be replicated</para>
+ </sect3>
+ <sect3>
+ <title>Subscribing all the data</title>
+ <para>
+ The final step is to get all the data onto the new database. It is
+ simply done using the subscribe script.
+ <command>data/pgsql-8.2.3/slony/slonik_subscribe_set
+ 1 2 > /tmp/subscribe.txt</command>
+ the first is the ID of the set, second is which node that is to
+ subscribe.
+ </para>
+ <para>
+ will look something like this:
+ <programlisting>
+ cluster name = replication;
+ node 1 admin conninfo='host=rome dbname=mydb user=postgres port=5432';
+ node 2 admin conninfo='host=rome dbname=mydb user=postgres port=5433';
+ try {
+ subscribe set (id = 1, provider = 1, receiver = 2, forward = yes);
+ }
+ on error {
+ exit 1;
+ }
+ echo 'Subscribed nodes to set 1';
+ </programlisting>
+ send it to the slonik
+ <command>cat /tmp/subscribe.txt | /data/pgsql-8.2.3/bin/slonik
+ </command>
+ </para>
+ <para>The replication will now start. It will copy everything in
+ tables/sequneces that were in the set. understandable this can take
+ quite some time, all depending on the size of db and power of the
+ machine.</para>
+ <para>
+ One way to keep track of the progress would be to do the following:
+ <command>tail -f /var/log/slony/slony1/node2/log | grep -i copy
+ </command>
+ The slony logging is pretty verbose and doing it this way will let
+ you know how the copying is going. At some point it will say "copy
+ completed sucessfully in xxx seconds" when you do get this it is
+ done!
+ </para>
+ <para>Once this is done it will start trying to catch up with all
+ data that has come in since the replication was started. You can
+ easily view the progress of this in the database. Go to the master
+ database, in the replication schema there is a view called
+ sl_status. It is pretty self explanatory. The field of most interest
+ is the "st_lag_num_events" this declare how many slony events behind
+ the node is. 0 is best. but it all depends how active your db is.
+ The field next to it st_lag_time is an estimation how much in time
+ it is lagging behind. Take this with a grain of salt. The actual
+ events is a more accurate messure of lag.</para>
+ <para>You now have a fully replicated database</para>
+ </sect3>
+ <sect3>
+ <title>Switching over</title>
+ <para>Our database is fully replicated and its keeping up. There
+ are few different options for doing the actual switch over it all
+ depends on how much time you got to work with, down time vs. data
+ loss ratio. the most brute force fast way of doing it would be
+ </para>
+ <orderedlist>
+ <listitem>
+ <para>First modify the postgresql.conf file for the 8.3.3 to
+ use port 5432 so that it is ready for the restart</para>
+ </listitem>
+ <listitem>
+ <para>From this point you will have down time. shutdown the
+ 8.2.3 postgreSQL installation</para>
+ </listitem>
+ <listitem>
+ <para>restart the 8.3.3 postgreSQL installation. It should
+ come up ok.</para>
+ </listitem>
+ <listitem>
+ <para>
+ drop all the slony stuff from the 8.3.3 installation login psql to
+ the 8.3.3 and issue
+ <command>drop schema _replication cascade;</command>
+ </para>
+ </listitem>
+ </orderedlist>
+ <para>You have now upgraded to 8.3.3 with, hopefully, minimal down
+ time. This procedure represents roughly the simplest way to do
+ this.</para>
+ </sect3>
+ </sect2>
+
</sect1>
More information about the Trad
mailing list